Mark Ramm wrote:
> I think it has to be a header, because the environ may be copied out
> by some middleware between repoze.who and the actual WSGI app that
> throws the 401.

That settles the matter then, a header it should be.

- C

  Other than that, everything sounds good to me.
> --Mark
> On Tue, Dec 16, 2008 at 8:22 PM, Chris McDonough <> wrote:
>> Gustavo Narea wrote:
>>> Hi.
>>> 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) 
>>> was
>>> 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 
>>> login
>>> 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
>>  message.
>> - 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 
>> necessary).
>> 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.
>>> Gustavo.
>>> On Tuesday December 16, 2008 00:06:01 Jorge Vargas wrote:
>>>> Hello,
>>>> 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

Repoze-dev mailing list

Reply via email to