Gustavo Narea wrote:
> I've read the code for the RedirectingFormPlugin and I think that in our
> situation, one solution would be to write our own RedirectingFormPlugin-like
> plugin, adapted to what we want.
> Although I think it'd be even better if RedirectingFormPlugin (optionally)
> able to redirect to an intermediary page (e.g.,
> "/login_validation?came_from=...") which will redirect to the "came_from" URL
> if login succeeded or the login page otherwise. I can write a patch if it
> sounds sensible.
> And the third solution that comes to my mind would be to write a repoze.who
> identifier that will insert a variable in the environ if the user comes from
> the login handler (e.g., with the key "just_logged_in", equal to True if
> succeeded or False otherwise) -- in fact it doesn't _has_ to be a repoze.who
> identifier. Then, when the app finds this variable and it's False, I will
> redirect to the login page (possibly with a parameter in the query string,
> like failed_login=1).
> Is there a fourth solution better than the three ones above? If not, what's
> the best of the three?
Inasmuch as it's the application's decision about whether to perform a challenge
or not (by eventually doing "abort(401)" in TG's case), it should probably also
be the application's decision to optionally attach a message about *why* the
authorization was denied. This could be done by:
- Permitting the application to set a response header which contained the error
- Permitting the application to set an environment variable which contained
the error message.
In either case, the .challenge method of the RedirectingFormPlugin could scrape
the error message out of the headers or environ, and inject it as a querystring
parameter into the URL which it redirects to that shows the login form. The
form that showed the login page could then use that error message to place it in
a box on the login form. If just showing the error message about why
authorization failed on the login form wasn't enough, in advanced setups, the
presence of this query string parameter could then be used by whatever rendered
the login page to do something "else" (redirect to a different page, if
This would require making a decision about header-vs-environment (I don't have a
preference really), and then just changing the challenge method of the
RedirectingFormPlugin to scrape it and inject it into the "location" URL query
string (much like it already does for "came_from").
How does this mesh with TG folks' expectations?
> Thanks in advance.
> On Tuesday December 16, 2008 00:06:01 Jorge Vargas wrote:
>> I'm working on upgrading the turbogears quickstart tutorials to
>> provide a nicer integration with repoze.who/repoze.what
>> One feature we are missing is the display a "Login Failed" message, I
>> was discussing this over with Gustavo and we didn't came up with a
>> simple answer so far.
>> Turbogears quickstart is using RedirectingFormPlugin and we have our
>> build in flash which stores things on the Session, so ideally we
>> should be calling tg.flash from inside the code that says "if login
>> failed go back to /login". how can we accomplish this?
>> Bonus points if we could allow a customization of the error message
>> with a callback or parameter.
>> As a side question, which will be the advantages/disadvantages of
>> dropping the redirecting form, and use a simple form plugin? keep in
>> mind the TG quickstart is aimed at two sets of people.
>> - newbies that want to try out the framework
>> - experienced developers that want to start a new application with
>> sane defaults.
>> Therefore the solution we apply here not only has to be easy but
>> production ready. If using a FormPlugin complicates things a little
>> but provides more flexibility I'm willing to do that sacrifice.
>> Anyway thanks for your help.
>> Repoze-dev mailing list
Repoze-dev mailing list