codesite-nore...@google.com wrote: > (ALL users get > session records, regardless of whether they're logged in.) The User > class now does not use its own cookies to handle logged-in-ness, but > instead uses the PHP $_SESSION['user_id'] variable. Added > Session::set_userid() and Session::clear_userid() for the purpose of > storing that information in the settings table to do things like query > for logged-in users.
A thought occurred to me on one possibly very cool use for the new session stuff: built-in sudo functionality
If the user has sufficient privilege, they can "become" a different user on the site. User::identify() would query the $_SESSION['sudo'] for the effective user ID, and would use that when returning a user object. User::can() would similarly honor $_SESSION['sudo'] when determining what you can and cannot do.
In this way, an admin can verify the configuration / settings for particular users without having to log out and back in multiple times.
We would need to update the admin interface in a number of places to make this work properly without being too confusing. For example, the "logout" link at the bottom would need to indicate that logging out would be to exit the sudo session. Maybe a status indicator in the top admin bar would be helpful to show who you are logged in as, as well as any sudo user you're currently operating as.
> codesite-nore...@google.com wrote: >> (ALL users get >> session records, regardless of whether they're logged in.) The User >> class now does not use its own cookies to handle logged-in-ness, but >> instead uses the PHP $_SESSION['user_id'] variable. Added >> Session::set_userid() and Session::clear_userid() for the purpose of >> storing that information in the settings table to do things like >> query >> for logged-in users.
> A thought occurred to me on one possibly very cool use for the new > session stuff: > built-in sudo functionality
> If the user has sufficient privilege, they can "become" a different > user > on the site. User::identify() would query the $_SESSION['sudo'] for > the > effective user ID, and would use that when returning a user object. > User::can() would similarly honor $_SESSION['sudo'] when determining > what you can and cannot do.
> In this way, an admin can verify the configuration / settings for > particular users without having to log out and back in multiple times.
> We would need to update the admin interface in a number of places to > make this work properly without being too confusing. For example, the > "logout" link at the bottom would need to indicate that logging out > would be to exit the sudo session. Maybe a status indicator in the > top > admin bar would be helpful to show who you are logged in as, as well > as > any sudo user you're currently operating as.
Another nice feature to add to this, is a to also be able to be become a guest user. Eg. see the site as a anonymous user, without having to log out to check if something looks different when browsing it.
-----Original Message----- From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On
Behalf Of Christopher Davis Sent: 24. november 2007 23:46 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: r1116
That would be a very cool feature for using Habari in a corporate environment. I say lets explore it.
Chris On Nov 24, 2007, at 12:00 PM, Scott Merrill wrote:
> codesite-nore...@google.com wrote: >> (ALL users get >> session records, regardless of whether they're logged in.) The User >> class now does not use its own cookies to handle logged-in-ness, but >> instead uses the PHP $_SESSION['user_id'] variable. Added >> Session::set_userid() and Session::clear_userid() for the purpose of >> storing that information in the settings table to do things like >> query >> for logged-in users.
> A thought occurred to me on one possibly very cool use for the new > session stuff: > built-in sudo functionality
> If the user has sufficient privilege, they can "become" a different > user > on the site. User::identify() would query the $_SESSION['sudo'] for > the > effective user ID, and would use that when returning a user object. > User::can() would similarly honor $_SESSION['sudo'] when determining > what you can and cannot do.
> In this way, an admin can verify the configuration / settings for > particular users without having to log out and back in multiple times.
> We would need to update the admin interface in a number of places to > make this work properly without being too confusing. For example, the > "logout" link at the bottom would need to indicate that logging out > would be to exit the sudo session. Maybe a status indicator in the > top > admin bar would be helpful to show who you are logged in as, as well > as > any sudo user you're currently operating as.
Christian Mohn wrote: > Another nice feature to add to this, is a to also be able to be become a > guest user. Eg. see the site as a anonymous user, without having to log out > to check if something looks different when browsing it.
The way I do this is to use a different browser: I log into sites using Firefox, and use Epiphany to see what the anonymous users will see. I suspect you could easily do the same with MSIE and Firefox on Windows.
Sure, and I do that, but a system like your sudo proposal could just as well be used? You could even make a link available, when logged in as admin, that switches between Guest and Admin views?
-----Original Message----- From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On
Behalf Of Scott Merrill Sent: 25. november 2007 00:19 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: r1116
Christian Mohn wrote: > Another nice feature to add to this, is a to also be able to be become a > guest user. Eg. see the site as a anonymous user, without having to log out > to check if something looks different when browsing it.
The way I do this is to use a different browser: I log into sites using Firefox, and use Epiphany to see what the anonymous users will see. I suspect you could easily do the same with MSIE and Firefox on Windows.
