On Feb 25, 4:06 am, Mark Ramm <[email protected]> wrote: > Well, it's not so much that we're caching the authorization, as that > we're setting a session cookie that says you're authorized when you do > the auth. And then just checking for info from the cookie on > subsequent connections. So you're only authenticated for as long as > that browsing session lasts. The impact of the fact that some users > keep sessions open for a very long time could be mitigated by setting > a relatively short expire time on the cookie too.
I'd argue that this just hides the problem, because ultimately you have no control over the cookie expiry time. You can hope the client honours the request but there's no way of compelling it to do so. So that's a potential security problem if there is an expectation of the user's current privileges being honoured. > But this is by no means a TG2 specific issue, but is the case for any > framework that doesn't re-check the authentication info on every > single request, and as far as I know that includes most frameworks. I don't doubt this is true, but it seems to be a interesting example of how the chosen abstraction is a bit broken, and perhaps how this process shouldn't be split up into separate components at all. When the 'naive' system used by a typical PHP system starts to beat the frameworks, it's possibly worth seeing if something has gone wrong somewhere! Looking at existing sites... on this page it's showing my email address and a drop down list of other groups I visit, which are in the original HTML sent by Google Groups. In another tab I'm logged into Facebook where it's showing a list of pages I am subscribed to updates to. On StackOverflow it has my username in the HTML along with my paltry reputation score of 315 and my small collection of badges. I understand the argument that going to the database for authorisation is a potential performance hit. But in almost every example I can find, accessing a page while logged in has caused the app to go to the database, to my particular user row, and to pull out some relevant information. So the database hit is already there. But because of the desire to split auth off into a separate process from application logic, you now have the problem of potentially having to request the same data in auth that you have in your app logic despite -probably- not really needing to do it in auth most of the time, knowing that it is an expensive operation. You cache it on the client and in a session and hope that's enough. The cost of this optimisation is a bit of security and reliability, ie. pages/controllers that deleted users can access. That's probably a rare case, but perhaps less rare is where someone's groups or permissions have been lowered, and I'm guessing (do correct me if I'm wrong) that it won't go back to check the database there either? We can't rely on the honesty of the client in such cases as they can keep the cookie around indefinitely. I'm guessing that can be hacked around by altering the server side of the session, but that is just going to reduce the window of exploitation, not close it. To try and be constructive, I'd suggest that ideally the system would be rethought so that authentication and/or authorisation is piggy- backed onto the almost ubiquitous database read to collect the user data for the current page or controller. (Of course, there doesn't necessarily have to be a physical database read involved - just a system whereby you can query a user's credentials and details.) The system then extracts all relevant auth details from the user at that stage and passes them where they need to go, before normal controller execution is begun with that same copy of the user data. That way, you still only have your typical and desired 1 DB read of the user per page with no additional overhead incurred by auth in 90% of cases, and you can ensure consistency between the user data provided to the auth processes and the user data available to the controllers. -- 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 -~----------~----~----~----~------~----~------~--~---
