On Saturday, 13 December 2014 08:31:52 UTC, Moritz Schlarb wrote: > > Well, > > to begin with: Which exact version of TG2 are you using and how did you > install it (virtualenv)? >
Yes, virtualenv, Turbogears2-2.3.4 > Am 13.12.2014 um 02:45 schrieb EoghanM: > > I'm a longtime TG1 user, and started a new project in TG2. I've just > > spent quite a number of hours trying to make the login page work, > > similar to the OP. Here's what I want to do: > > > > - Give appropriate error messages depending on whether the username > > exists or password is incorrect > > - Repopulate the username after an unsuccessful login attempt > > - Highlight whichever form field is incorrect > > It is commonly agreed that a login form should *never* ever tell you > which field is incorrect and whether the username already exists! > Because hackers, you know? > I agree that security-first is a desirable default, but there are strong counter arguments as to why hiding the error is overkill: https://kev.inburke.com/kevin/invalid-username-or-password-useless/ anyhow, that's besides the point — the main problem is that I can't repopulate the username. When I come across a website which throws away the username after an unsuccessful login attempt (it occasionally still happens) I assume the creators don't care about usability. I'd contact support to try to get it fixed if possible. > I haven't been able to do any of these as (I've learned) this > > functionality is delegated to repoze.who, and I can't find the place on > > my harddrive where the code for this lives. > > Well since it is a third-party package that was installed when you > installed TG2, it's in your virtualenvs site-packages folder. > You could find out by opening up a Python interpreter and executing > 'from repoze import who; print who.__path__' (not tested, but should > work). > Getting somewhere now: >>> import repoze; repoze.__path__ ['/usr/local/lib/python2.7/dist-packages/repoze'] It didn't get installed to the virtualenv although everything else did. Maybe I already had it installed from a prior attempt at TG2. I would have been able to drop a breakpoint in there if I had of figured this (searching for string 'repoze.who.userid'), and maybe tried to add specific failure info to the identity object. It doesn't look easy from a first look at the code, and is certainly not a good activity to have to do right after a quickstart. > > Searching in this forum for 'login_handler' shows that plenty of other > > people have also had this or similar problems. > > I can't do anything in the post_login controller, as it doesn't receive > > any information about what username was tried, beyond the fact that > > request.identity is empty. > > I tried adding custom middleware (similar to LoginCleaner), but adding > > the POST login user_name to the environ doesn't survive the redirects. > > I'm sure any serious user of TG2 (like Diez) has worked out how to get > > around this, as the items I've listed above are basic functions of a > > login page; the big concern would be as to why some sort of solution or > > replacement hasn't made it's way back into TG2 trunk yet. > > (I've no idea why repoze.who was chosen as a component, but for learning > > purposes, it's just a big magic black box). > > Replacing the TG2 auth with 3rd party code or something I rolled myself > > kind of defeats the purpose of using a framework (documentation & reuse > > of other peoples' recipes and extensions). > > Well yes, but the original premise of TurboGears was always to use > well-known and tested components and provide the "plumbing" between > them. repoze.{who,what} were the de facto standard for WSGI > authentication and authorization. That being said, those packages > themselves are of course documented on their own, so you should have a > look there: http://repozewho.readthedocs.org/en/latest/ > <http://www.google.com/url?q=http%3A%2F%2Frepozewho.readthedocs.org%2Fen%2Flatest%2F&sa=D&sntz=1&usg=AFQjCNE4huvG6gLGRaFUKFvInug4LuL2aA> > > (Sadly, it seems > the docs for 1.0.18 aren't available anymore) > Thanks, every reference I saw to repoze.who in the TG2 docs seems to point to non-specific and out of date docs. I'm still unsure as to whether TG2 uses the 'api' or the 'middleware' of repoze.who. A more specific link would still definitely be a help. > I do agree with you, that as an authentication framework, it seems > overly complex at first. But once you need to support different > authentication mechanisms in your application or need to provide a > customizable layer for your deployment, you are gonny appreciate it's > design. > Cheers, but ain't gonna need these, and further, I'd say for the majority of projects we can stop at the description of 'overly complex'. I'd have no problem adding extra modules or introducing extra complexity if I did need some of those alternate mechanisms. TG2 should include a 'native' way to login a user against the tg_user table (the one that is generated in the quickstart). It's a deal-breaker for me that this core bit of functionality isn't easily hackable and customizable (and that it doesn't do the right thing by default). Thanks for your help. Eoghan -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/turbogears. For more options, visit https://groups.google.com/d/optout.
