On Feb 25, 1:16 pm, Mark Ramm <[email protected]> wrote: > I know what you want. But it's probably not going to happen that > way, because there are good reasons for keeping authentication and > authorization separate. And there's no reason that they can't provide > what you want and still be separate.
Well, that at least is good to hear. > And we're working on making that an option. It could even become the > default option in the way tg2 is configured if enough people request > it. But it's not going to trigger a redesign of our whole auth > system. Well, it was worth a try. ;) > On the other hand, I know as a former system administrator who had to > remove login priviliges for employees who where accused of fraud, etc, > that LOTS of web and GUI systems check authentication only at the > start of a session. It is an incredibly common pattern, and there > are performance reasons for it. But are you saying that there was never a problem or potential problem with this, when you came to revoke people's privileges? Problems that would have been solved if this was done the safe way rather than the fast way? Or to put it in the current context, what action would you expect to take if you found yourself needing to immediately prohibit someone's access to a certain TurboGears controller which they had previously had access to? I'm a game programmer by trade and yet even I would try to prefer the safe way over the fast way if possible. It's usually easier to retroactively speed up the slow parts of a system than to secure the insecure parts. So I'm surprised people are doing it this way and still think that it's ok. I appreciate that 99% of the time security holes aren't a problem, but that's exactly why they're problems - you develop your system under the impression that everything's safe and working the way you expect, and then someone finds the corner case later. > I mean do you > actually know that Facebook, Yahoo, Gmail, etc check your credentials > on every request? No, I don't know that they do, and in some cases I know for certain that Facebook doesn't do that, but that is more down to the way they push events around the system rather than pull them. Either way I was just illustrating that the database read isn't a big problem since everybody is doing it. I know some sites use other methods like LDAP, but I like to think about the simple case and keeping that simple (and correct). > And all of your argument is predicated on one relatively cheep > database hit for authentication, but I expect tg2 to be used with > OpenID providers, LDAP, Kerberos, etc. And many of these require > hitting someone else's server to authenticate a user, which should not > be done on every request. Well, my argument is predicated on doing the right thing for the common case, which I believe is the trivial username+password => current User object mapping. Unfortunately it seems like a system that is designed to elegantly handle the less common cases too and this means sacrifices have to be made. I would suggest the way around this is to add a proxy layer before those providers, so that the caching is done by this proxy, not by the authentication system as a whole. If you're using LDAP or something and checking a user takes too long, turn on the proxying and it can start returning the cached groups/permissions/whatever for that user. > And if what you're saying is that authorization should be rechecked on > every request, that's a separate issue from authentication. Well, my original point was just that there should be a simple and foolproof way - in the guise of a controller decorator or predicate for an existing decorator - that verifies that the user/groups/ permissions are valid at the time of the request (for security), and it can guarantee the existence of an associated User object within that controller (for reliability). The second can presumably be done with Gustavo's UserStillExists snippet above, but I don't know how you'd fix the former when it comes to groups and permissions. Either way, I think I was just misled because there's a general concept of Identity (perhaps instilled in me from TG1) which gives the expectation that I can check the identity in/around a controller and get a valid and current User back. This new system allows me to check the identity, be told there's a user, and yet not actually find a user where I expected to see one. Or, if I understand it correctly, be told that the user can access certain features that he shouldn't be able to, because he's not chosen to log his client out yet. I'd love to see something that streamlines this process, circumventing these issues, and which is presented as an alternative to not_anonymous for trivial auth systems, with the caveats of each alternative pointed out to the user. -- 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 -~----------~----~----~----~------~----~------~--~---
