On Saturday February 21, 2009 17:30:55 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.
Well, the Repoze mailing list seems like the right place if you want to discuss about that. > 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. The only person who has mentioned all that stuff in this conversation is you, noone else. Come on, you know *noone* suggested what you stated above. I said *clearly* "metadata providers", nothing else. Or, did I point you to the repoze.who website? No, noone did. > Why punish the typical user to make life better for the advanced user? >From my point of view, you describe a particular meaning of "typical 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. Regarding the auth* docs on TG, I think that anybody who takes 5 minutes to read the whole auth documentation will learn all they need to do advanced stuff, possibly with the help of the external docs. But anyway, this point is irrelevant in this conversation. Nobody else has told you that you have to read the repoze.who docs to do this. I provide you with the code you need and pointed to a short page in case you want to learn more about what it does. It can't be simpler. > > > 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. Yes, and that's an authentication-related task which can be perfectly done by repoze.who. > > 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. repoze.what is not going to deal with authentication. It will continue assuming that the identification data provided by the authentication layer is correct. A generic solution can *only* be implemented in the authentication layer. If you want, you can write that repoze.what predicate checker in which you mix authentication and authorization. > 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.) You definitely misread those docs. Of course it says what's in the identity dict. > 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. Of course there's a current user. That's what the authentication layer says. > 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. Right, and you can force such a verification by copy/pasting 10 lines of code but still consider it hard! > 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. Well, I already told you that if you're sure most people want that by default, you should start a poll. > > > 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.htm > >l > > 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!) Please don't distract attention from this. You know I was talking about repoze.who plugins, in response to your statement. But now that you bring unrelated issue, here's the response: Yeah, that's not covered by the TG2 docs yet. But does it make it irrelevant? > > 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. I have nothing else to say. If you are so confident that most people will support you, then start a poll. Cheers. -- Gustavo Narea <http://gustavonarea.net/>. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
