Well,
to begin with: Which exact version of TG2 are you using and how did you
install it (virtualenv)?
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 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).
> 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/ (Sadly, it seems
the docs for 1.0.18 aren't available anymore)
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.
Moritz
> 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,
>
--
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.
