On Feb 21, 3:47 pm, Gustavo Narea <[email protected]> wrote: > On Saturday February 21, 2009 14:58:22 Ben Sizer wrote: > > Just like TG doesn't handle CRUD operations on databases by itself, but uses > SQLAlchemy instead, TG2 doesn't handle authentication or authorization by > itself either -- instead it uses repoze.who and repoze.what, respectively.
And expecting the typical TurboGears user to understand those systems is asking too much. The repoze.who system is obviously geared towards "making complex things possible" at the total expense of "making easy things easy". The documentation at http://static.repoze.org/whodocs/ is extremely thorough, rigorous, accurate, and almost completely inpenetrable. Never forget that the average developer just wants this: - have a user enter a username and password - log them in if the username and password match an existing User record - restrict parts of the application to clients who pass the above test - have access to the User record in question We are talking about a system that requires about 5 or 6 lines of PHP code, or indeed plain Python: open DB connection, select user where username and password match, fill an associative array with the content. If TurboGears forces a new user to have to go to an external site, and then learn about Configuration Points, Classifiers, Challenge Deciders, Plugins, Request (Ingress) Stages, Response (Egress) Stages, Identifier Plugins, Authenticator Plugins, Metadata Provider Plugins, Challenger Plugins, Authenticator Plugins, Challenger Plugins, and Metadata Provider Plugins, to do this, then you have completely failed to make easy things easy. Why punish the typical user to make life better for the advanced user? > So, with this in mind, it's definitely a meaningful detail for someone using a > NIH Web application framework. If TG was a monolithic framework like Django, > it'd be meaningless -- but it's not. It is only my opinion, but I believe that TG should make it simple to do the basic tasks with only minimal reference to external docs. That is how it was in TG1, once the docs settled down. The original 'About Turbogears' stated that it doesn't *obscure* each included project, which *allows* you to take advantage of all existing documentation. Note that "doesn't obscure" and "allows" implies that the advanced functionality is there if you need it, which is a quite different emphasis from saying that you need to have learned several pieces of external documentation to perform even the most basic task. > > We need a controller decorator that will say "only allow access to > > this resource if the user actually exists and is logged in". > > not_anonymous may well be the wrong one for this. But there needs to > > be a 'right one' because I would argue not_anonymous is not really > > very useful to TurboGears if it cannot guarantee that the > > authenticated user actually exists. > > To be honest, that doesn't make any sense. What you propose is mix > authorization with authentication. I disagree. It makes perfect sense. You're looking at it from the implementation point of view where you separate these concerns, but that's irrelevant from the outside. Typically you don't care about the distinction. You want to find out if the client corresponds to a current user so that certain controllers only operate when they have a logged-in user - that's all that matters. > I want you to know that I understand your request, I think it definitely makes > sense. What doesn't make sense to me is the solution you propose -- it must be > dealt with in the authentication layer, nowhere else. All I care about is this: there should be a one-line decorator that I can apply to a TurboGears controller which guarantees that either: a) I am barred from the controller, and presumably redirected to a login page, or b) I get to enter the controller, and the request.identity's User object is valid within it. How that is implemented that is of less interest to me. Arguing about which layer it belongs in is something I am not qualified to do, but the danger there is that everybody says "well, it doesn't belong here" and then it never gets done. Often real life use cases don't fit neatly into the clean abstractions we've chosen for our software, but that doesn't make the use case less valid, just the abstraction. > > So, can someone wrap up the above and put it in TG2 under an intuitive > > name? (And then add to the docs?) All the talk of metadata and > > providers is fine for advanced users but there should be a basic and > > built-in system in TG for this simple and common use-case. > > Just like the talk of database sessions in SA is for advanced users? There's > no such a "built-in" auth* system in TG2. TG2 itself doesn't handle > authentication, identification or authorization, unlike TG1. Have you > readhttp://turbogears.org/2.0/docs/main/Auth/? Yes, I have, and sadly it's not much use as it tells you next to nothing about how to actually use this system in practice. http://turbogears.org/2.0/docs/main/Auth/ - mainly just tells you how to set it up with quickstart, which is already covered elsewhere I think. http://turbogears.org/2.0/docs/main/Auth/Authentication.html - tells you how it was implemented, most of which is irrelevant to the typical user since this was already done for them. It's handy for people who are familiar with repoze but new to TurboGears, which probably constitutes about 2% of the readership. It also refers to an 'identity dict' without making any mention of what might be in it that you can use. (I added a comment on the page to this effect.) http://turbogears.org/2.0/docs/main/Auth/Authorization.html - this is more useful, but lacks clarity. eg. "class repoze.what.predicates.not_anonymous - Check that the current user has been authenticated."... this is misleading as there is actually no 'current user' in the situation I talk about. The current -request- or -client- has been authenticated against a user at some point, and we have a username, but there is no current user here. It's even possible that the username in question actually refers to a completely new user who has been created in the meantime. With TG1, and Identity, you would use identity.require() on a controller, and would have access to identity.current as your User object in the controller. I have no doubt that this is exactly what most people need, not fine-grained control over distinctions between authorisation and authentication bought at the expense of this simple access to a user. If that is outside the scope of repoze, then TG2 needs to fill that gap, in my opinion. It may just be a case of using the example code you posted above. But it needs to be part of TG2 and part of the docs. There shouldn't be a step backwards in usability and conciseness from TG1 just to support esoteric auth needs. > > The > > philosophy of "make easy things easy, and hard things possible" should > > mean that the absolutely most common case - where you simply want to > > confirm that someone has entered a username and password which matches > > up to an existing User in the database - should be 'easy', and not > > involve learning about metadata providers etc. > > This won't sound like Chinese for those who bothered to take a couple of > minutes to read the relevant > documentation:http://turbogears.org/2.0/docs/main/Auth/Authentication.html Sorry, I completely disagree, and think that 'relevant documentation' is very lacking. Can you point out where, in that documentation, it tells me how to actually get a 'User' object back from this system, which is surely what most people will need to do? (Ignoring my comment at the bottom of the page - that would be cheating!) > This verification on *each* request affects performance, at least slightly. > This is why I'd prefer that people who really want it have to enable it by > themselves... Unless there's a consensus where most people think this should > be the default behavior. If there is a separate decorator provided for this, with an explanation of the pros and cons of each, I think that would suit most people. -- 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 -~----------~----~----~----~------~----~------~--~---
