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 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. 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). Eoghan On Wednesday, 12 June 2013 17:31:34 UTC+1, Alessandro Molina wrote: > > Doesn't the authenticator get the environ of the current request as > parameter of the authenticate method? > You can store there any parameter you want to pass to the application and > retrieve it from request.environ. > > That is the quickest solution I can think of > > > > On Tue, Jun 11, 2013 at 12:41 AM, Carl Antuar <[email protected] > <javascript:>> wrote: > >> I've run into this problem recently at work, when we wanted to lock >> accounts with a custom message after too many failed retries. >> >> Thus far, the best (but still ugly) workaround that I've found is to have >> our custom Repoze authenticator add a query string parameter to the >> FriendlyFormPlugin post_login_url property, then look for that parameter in >> the controller. It's not totally reliable - sometimes the parameter doesn't >> arrive in the controller, perhaps due to caching of some kind - but it >> often seems to work. >> >> I wish Repoze would pass through the username that was attempted when it >> is reporting a login failure to the application, so that the application >> could check up on that username and figure out the cause of failure. Or >> simply allow custom parameters to be set in the authenticator and passed >> through to the app. Haven't found a good way yet. >> >> >> On Tuesday, 9 November 2010 02:31:08 UTC+10, Yannick Gingras wrote: >>> >>> >>> Greetings TG users, >>> I have been digging down in the auth code that I get from the quick >>> start and there does not seem to be a way to have custom error >>> messages for login failures. I see that I can change the flash >>> message but nevertheless, it's one message for all the possible >>> failures. >>> >>> What would be a the least painful way to have custom messages for >>> cases like: >>> - no user name >>> - no password >>> - invalid password >>> - user account has been locked by site admins >>> >>> Doing that at form validation time would be trivial so I'm thinking of >>> stripping the friendly form plugin from the equation but I can't see >>> an easy way to do that. >>> >>> Would it be easier to tell TG not to initially the auth stack and to >>> create the repoze.who auth cookied by hand? >>> >>> Thanks in advance for your help, >>> >>> -- >>> Yannick Gingras >>> http://ygingras.net >>> http://montrealpython.org -- lead organizer >>> http://ajah.ca -- technical lead >>> >>> -- >> 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] <javascript:>. >> >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/turbogears?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- 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.
