I just came across a situation where a not_anonymous predicate was true for a user that doesn't exist. This is because the user used to exist, and then got deleted, but the client's cookie remains. Presumably whatever information is in the cookie is sufficient to count as being authenticated even though that user may no longer exist. The end result is that although it may seem intuitive that the 'not_anonymous' predicate would be enough to restrict a controller to your existing users, this appears to not be the case.
This in turn means that the assumption that you can retrieve a User object from the request.identity when within a controller guarded by not_anonymous is false, as some of the things you expect to be in the identity dictionary are absent - the 'repoze.who.userid' value and the timestamp value are set but userdata, tokens, user, groups, and permissions are empty or None. I would argue that this is a bug, although I can certainly see why it might be deliberately done this way for efficiency. Perhaps therefore there needs to be 2 separate predicates, one lightweight like this which checks the user has been authenticated at some point, and another which checks that the user is still 'authentic'. What do other people think? -- 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 -~----------~----~----~----~------~----~------~--~---
