“苏”相当于 Web 应用程序身份验证、设计问题
我开发并维护一个用 Perl/Catalyst 编写的客户门户。我们使用 Catalyst 身份验证插件(带有 LDAP 存储后端,加上一些 Deny_unless 规则,以确保正确的人员拥有正确的组成员身份)。
通常,在管理客户的权限时,我们需要在交付之前测试用户的设置。目前,我们唯一的办法是重置用户密码并自己登录,但这不太理想,特别是如果用户已经设置了自己的密码等。
我的问题是:对于 Catalyst,有没有人遇到过一种方法模拟用户帐户,以便在获得正确的超级管理员权限的情况下,可以在测试设置时暂时模拟另一个帐户,然后在完成后退出?
如果不是在 Catalyst 中,那么人们如何在其他框架或他们自己的自定义解决方案中解决这个问题?诚然,这会给 Web 应用程序带来潜在的严重攻击向量,但如果强制实施,人们如何为此进行设计呢?也许是一些严肃的cookie-session-fu?或者可能是实际ID/有效ID 系统?
I develop and maintain a customer portal, written in Perl/Catalyst. We make use of the Catalyst authentication plugins (w/ an LDAP storage backend, coupled with a few deny_unless rules to ensure the right people have the right group membership).
It's often that in managing a customer's permissions, we have the need to test out a user's settings before we hand things over. Currently, our only recourse is to reset a user's password and log in ourselves, but this is less than ideal, particularly if the user has already set their own passwords, etc.
My question is this: for Catalyst, has anyone come across a method of impersonating a user account such that, given the correct super-admin privileges, one could impersonate another account temporarily while testing out a setting, and then back out once done?
If not in Catalyst, then how have people approached this in other frameworks, or their own custom solutions? Admittedly, this is something that introduces a potentially egregious attack vector for a web application, but if forced to implement, how have people approached design for this? Perhaps some serious cookie-session-fu? Or possibly an actualID/effectiveID system?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们使用自定义身份验证器控制器、自定义用户类 (MyApp::Core::User) 和几个领域:
在
myapp.conf
中,我使用如下内容:这样我们就创建了一个普通的 Catalyst user 对象,但将其包装在我们的自定义用户类周围以获得更多控制。我可能可以创建一个专门的代理领域,但我选择使用我自己的用户类。这是不久前完成的,我还记得我们为什么这样做。
We use a custom authenticator controller, a custom user class (MyApp::Core::User) and several realms:
In
myapp.conf
I use something like this:That way we're creating a normal Catalyst user object, but wrapping it around our custom user class for more control. I probably could have created an specialized realm for surrogating, but I've chosen using my own user class instead. It was done a while back and I can recall why we did it that way.