I think the reasoning is that "Interpret the current user id from a cookie / kerberos authentication / some key in the session"
and "see whether the identified user exists in our system" should be in different layers. I agree this leaves me scratching my head as to when the distinction is useful. My first guess was 'the time between deleting a user from the database and the expiration of an authentication cookie', except I never delete users from my database, I would remove all their group memberships instead. I am used to systems that allow any username to be logged in but don't give any useful permissions unless that user actually has an account. Think of passing REMOTE_USER from a single sign on system, or a system that uses an openid as the userid. The application will only know about a few of these users but they will be logged in whether or not they exist in the application's database. While writing this example, perhaps this distinction could be used to offer a 'create account' form to a user who had just presented a new openid? I'm not entirely sure why that feature wouldn't just be a special group. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
