On Feb 21, 5:25 pm, Gustavo Narea <[email protected]> wrote: > On Saturday February 21, 2009 17:30:55 Ben Sizer wrote: > > > 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.
No, I think this is the place to discuss it. If the purpose of Repoze is to facilitate these complex authentication and authorisation processes then it's perfectly fine for it to be geared towards those cases. The only problem is that TurboGears relies upon it for its default auth provision. Therefore the simple case should be simple. If Repoze's simple case is not simple, then TurboGears should wrap it accordingly. > > 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. It was implicit in you saying "TG2 doesn't handle authentication or authorization by itself either -- instead it uses repoze.who and repoze.what, respectively. So, with this in mind, it's definitely a meaningful detail for someone using a NIH Web application framework." That is implying that the rules of repoze are what govern auth in TG2. So you need documentation on repoze, except that what is in the TG2 docs tells you next to nothing on how to use it. > > 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". Do you truly believe that most people need more than simply to map users and passwords to User objects? I may have 'only' done web development for 9 years but that is precisely what I needed on pretty much every site I made. > 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. I find this attitude baffling. This isn't about me getting a simple answer to my situation. It's about pointing out an apparent deficiency in the software, the docs, or both, and trying to get opinion on what the best way to resolve it is. Software development shouldn't be about scouring Google Groups to try and find a snippet for what you want. I think it needs to be rolled into the software and the docs at some point. That's all. > > 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. It's a very useful task which should be available to TG2 users right from the start without needing to know to search for metadata providers. That is all I am saying. > You definitely misread those docs. Of course it says what's in the identity > dict. Where? The only information I can find is "The username will be available in identity['repoze.who.userid']". That's it. I am happy to be wrong if I learn something in the process but I have scoured the TG2 auth docs for details on how to get a User object back and eventually had to find out through trial and error, printing out the items() of the identity dictionary. > >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. There is no current user whatsoever. The information in the cookie looks like a valid user and presumably the hash looks legitimate, but it /does not/ map to an existing user. There is a client making a request while successfully identifying as a past user, but this is not a current user, given any reasonable definition of 'current'. > Right, and you can force such a verification by copy/pasting 10 lines of code > but still consider it hard! The typical TG user should not have to search this group to find the correct 10 lines of code to copy and paste just for the default login system to work the way that you'd expect it to. I refuse to accept that is the way it's intended to be. I am grateful for you posting the code to achieve this task, but I am suggesting to this group that this should form part of the TG2 system in some way. > > 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. A poll with which options? What would the choices be? All I want is for repoze to be wrapped and documented in such a way that it is no harder to use than Identity was, in the default case of simple name/ password => User systems. I doubt there is anybody at all who would vote against it, saying "no, I like the additional complexity, it makes me feel like a better programmer". The issue is whether it's practical to change and/or extend it or not. Hence this discussion. I'm not surprised that you fully support your own work in repoze.what, and indeed I have no criticism of what repoze.what does or how it does it. My only concern is that a typical TurboGears 2 user will have an expectation that if they enable auth in their quickstarted application then it will be simple to use for the simplest task, ie. guarding access to controllers via username/password combinations, and getting hold of the User in that situation. As it stands, the first works almost all the time apart from the flaw where you can log in despite your User having been deleted, and the second appears to me to be undocumented. > > > 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 > > > 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. No, really I don't. You posted 'http://turbogears.org/2.0/docs/main/ Auth/Authentication.htm', and that is what I read. It contains a reference to metadata plugins but does not explain how that is relevant to much at all, to be honest. You're answering this as if I am a user requiring technical support. I am just stating that what you seem to think is obvious and well- documented really is not. You are one of the repoze developers so it's understandable that you know exactly how your system fits into TurboGears and how to make best use of it. But most people will not. The repoze docs are fine but they are very abstract and for advanced users. The TG2 docs are simpler but are currently minimal and don't tell you everything you need to know. > 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? My original post was to draw attention to issues of clarity, with the hope that someone who knows about the system can document it. Apologies for the length of this message. -- 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 -~----------~----~----~----~------~----~------~--~---
