[mod_python] Custom Login with redirection back to referer

Graham Dumpleton wrote:
> 
> On 20/05/2006, at 4:38 PM, Deron Meranda wrote:
> 
>> On 5/20/06, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
>>> The HTTP specification actually says for 307 (Temporary Redirection),
>>> which is what one would want to use:
>>
>> Yes, that works too and is quite common, although be aware that
>> most older browsers don't understand a 307.

But I suspect if browser is too old to understand a 307 redirect, most 
web pages that user visits are almost completely unreadable anyway. :) 
It's up to the designer to decide if supporting stone-age browsers is 
worth the effort.

>  So put a link
>> on the redirecting HTML page as well.  I'd stay away from a
>> 302 though because it's semantics are more ambiguous.
>
> Arrggh, I actually meant to say 302 and not 307, as util.redirect()
> uses a 302. The specification still says much the same thing.
> 
>   The requested resource resides temporarily under a different URI. Since
>   the redirection might be altered on occasion, the client SHOULD continue
>   to use the Request-URI for future requests. This response is only 
> cacheable
>   if indicated by a Cache-Control or Expires header field.
> 
> Thus same argument should apply unless browser/cache is truly old.
> 
>> I still prefer to send back a 401 or 403 as the semantics are
>> much more explicit as to what is happening (the user
>> doesn't have permissions to view the page).  This may be
>> important if you want to adhere to a REST design.  Also,
>> unlike redirects of various flavors, a 40x won't confuse any
>> spiders crawling your site (whether a public search engine,
>> or your own indexer, or perhaps even a site mirror-er).
>> Other rare edge cases could also occur with redirects, such
>> as a user doing a "save target as" where the link is to a URL
>> requiring login first.  Rather than seeing an error message, the
>> user may later find that the file they saved was actually the
>> HTML source to your login page.
>>
>> This is mostly academic of course, but the intended purpose of
>> a 30x redirect is to say that the resource (or equivalent) which was
>> supposed to be at URL A can instead be found at URL B.  But in
>> this scenario that's not what you're doing.  URL A is simply not
>> accessible because of permissions, and URL B is a completely
>> different resource---the login page.
>>
>> But do what you want.  Many/most sites use 30x.  The main
>> disadvantages of the 40x codes is that there is no auto
>> reloading; and that can often be more important than having
>> the precisely correct semantics.  With a 40x, the user will have
>> to click on a link on the error page to get to the login page.
> 
> Can't one use JavaScript or HTTP-EQUIV header in 40x error response
> to get browser to redirect automatically?
> 
>> But then again, depending on your usability philosophy, that
>> may be more desirable.  Seeing an error page saying you
>> need to login before your can view the page may be less of
>> a surprise then just seeing a login form when you expected
>> something else, with no explanation why.
> 
> What is you attitude on having the login form in the 40x error page itself?
> 
> Anyway, see where you are going now. What I'll do is post up my session
> login stuff using 302 redirects, and then if I have time, will try and 
> modify
> it to use ideas you are talking about and see if we can't come up with code
> for each which people can compare. Someone will just have to convert
> my code to work with mod_python 3.2.8. :-)

Not completely on topic, but since we are talking about 30x redirects, I 
thought I'd mention that I've modified util.redirect to support any of 
the 30x codes. It's a pretty simple change, where util.redirect becomes

def redirect(req, location, permanent=0, status=None, text=None)

If status is not None it overrides the permanent parameter. I want this 
so I use util.redirect with a 303 HTTP_SEE_OTHER response after creating 
a resource with a POST. (for the POST-REDIRECT-GET pattern used in 
RESTful applications).

I haven't created a JIRA issue or checked in the code just yet. I figure 
if I'm are going to change redirect I may as well do it right and make 
sure we comply with RFC-2616, which may be a bit more work.

The 304 HTTP_NOT_MODIFIED redirect looks interesting in particular, but 
has some specific requirements for a couple of headers. I'm not sure if 
we should be doing any error checking in the util.redirect(), or just 
assume that if the user wants do this they know what they doing and have 
set the response headers accordingly.

If anyone has a couple of spare minutes perhaps they could peruse 
http://rfc.net/rfc2616.html#s10.3 and let me know what they think.

Jim