On Feb 21, 2:36 pm, Remi Jolin - SysGroup <[email protected]> wrote: > le 21.02.2009 15:03 Ben Sizer a écrit: > > > 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.
I am not doing anything with sessions, nor would I expect to have to do so. I don't have to do anything to sessions to add a user, nor when they log in - that is handled by the system. If sessions persist across TurboGears instances but are not kept in sync with the state of the Users database, that would seem to be wrong to me. Besides which, there are numerous ways in which you can add or remove a user from the system without being within the TurboGears environment - I would assume any auth based on external data sources such as LDAP can add or remove users arbitrarily without TurboGears getting a chance to modify any sessions. It would seem that the data in such sessions need to be validated against the data store every time they are used if they are to be accurate. Let me put it this way - if not_anonymous being True can't guarantee that I can get a valid User object, then what use is it to TurboGears? I appreciate it may have other uses, especially in the context of separate authentication and authorisation, but the typical TG use case will surely be that of restricting access to a controller to those whose login details map correctly to an existing User object, so that the code can make use of the data in that User object. If not_anonymous has good reasons for not doing that, then I would say there needs to be a new predicate that does it instead. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
