le 21.02.2009 15:03 Ben Sizer a écrit: > On Feb 21, 1:45 pm, Remi Jolin - SysGroup <[email protected]> > wrote: > >> le 21.02.2009 14:12 Gustavo Narea a écrit:> Checking whether the user really >> is authenticated (and "authenticated" means >> >>> that the user account really exists and the user provided the right >>> credentials on login) is a task specific to the authentication framework, >>> not >>> to the authorization framework. If the authentication framework says the >>> current user is authenticated, the authorization framework must not question >>> that -- that's out of its scope. >>> >> Yes. If you make a parallel with "connected" systems like a telnet/ssh >> session on a system, you don't get disconnected because the sysadmin has >> canceled/disabled your account. You will remain with the credentials you >> had at login time until you logout. If you don't want an identified user >> to remain connected after you disabled his account, I think that you >> should check who is "connected" and kill the corresponding sessions... >> > > The metaphor falls down because there is no connection, just an > illusion of one. On Unix I can easily kill all processes associated > with a given user before deleting an account. However, I do not have > the power to go onto someone's machine and delete their cookie to kill > the session they have with my webserver. They can hold onto that for > eternity, and it persists across me restarting the TurboGears process. > > What you would end up having to do is to manually check in each of > your controllers that the user that the client claims to be is > actually a real user in the database. I believe that 9 times out of > 10, when you use not_anonymous to guard a controller, that is because > you are expecting to have a working User object attached to the > request.identity. If you have to manually check the validity of that > each time, then the utility of using not_anonymous has dropped down to > almost zero. > There is no connection but there are sessions that keep track of who is who. The cookie is just a "reference" to an actual session on the system. On the controller, don't you have a list of the current authenticated sessions ? You don't have to kill the cookie to kill the session, can't you just kill all the sessions associated with the user you have just deleted the account ? This would force a re-authentication of the user the next time he tries to access a protected page.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
