[Catalyst] How to "sudo" using the Authentication plugin

Robert Rothenberg robrwo at gmail.com
Sat May 12 10:17:38 GMT 2012


Wait a minute: would your solution work with $c->check_any_user_role?

On 12/05/12 11:09 Robert Rothenberg wrote:
> On 11/05/12 19:18 Tomas Doran wrote:
>>
>> On 11 May 2012, at 17:45, Robert Rothenberg wrote:
>>
>>> We're working on an application with a lot of users, and where the passwords
>>> are encrypted (and future versions may also allow OpenID logins).
>>>
>>> Developers would like the ability for the "root" user to be able to become
>>> another user, for the purposes of debugging problems that real users might
>>> be having on a live system.
>>>
>>> How does one do this using the Authentication plugin?
>>>
>>> Obvious things to try like the $c->user($new_user) doesn't work, not does
>>> the (internal) $c->set_authenticated($user, $real) method.
>>>
>>
>> The recommended approach would be to keep $c->user 'pure', and to arrange to stash the current user in a top level base chain part, or top level auto.
>>
>> If everything then subsequently uses $c->stash->{current_user} - then you can do your sudo (or whatever other mechanism you may need in future) simply by swapping out the user here.
>>
>> This makes things a lot more pure - as the canonical user that $c->user will give you is (more) immutable..
>>
>> Also, if you swap the 'canonical' user part way through the request - when the session plugin comes to re-serialize the session at the end of request - you're pretty stuffed, as you're now writing out the wrong user… I.e. re-sudoing, or doing any root level action is likely to require you to log out and log in again - not what you actually want! :)
> 
> We don't mind having to log out and log back in again after sudoing.
> 
> I'm not looking forward to changing every use of $c->user in the code, and
> concerned about how this might interact with any plugins that rely on $c->user.
> 
> Would you consider the ability to sudo a feature request for the
> Authentication plugin? (with appropriate thoughts about the security
> implications, of course).
> 
> Thanks,
> Rob
> 





More information about the Catalyst mailing list