Tue, 27 Nov 2012
Cookies Auth and 403 Forbidden
In IS MU we have recently abandoned the HTTP basic authentication and replaced it with cookie-based authentication. The main reason was that there is no portable way of logging out of the basic authentication. So I have based our new solution on Apache2::AuthCookie. The problem is, that it does not work correctly with some clients because of the way how the login form is handled.
When the yet-unauthenticated user accesses an URL for authenticated users only,
Apache2::AuthCookie returns the HTTP response with "403 Forbidden"
status code, and with text/html body containing the login
form. That way, the client cannot be possibly lead into the false assumption that the page it just received is in fact the content it wanted to receive.
So the user fills the login form, submits it, and the server returns the real
page for that URL, this time with "200 OK" status code.
This approach seems to be correct (even after reading the RFC 2616 :-). However, we observe problems with
the following two use cases:
- Nokia Symbian-based phones. After receiving 403 from the server, they display their own error message, and ignore the returned HTML altogether (except for the page background :-).
- Microsoft Word. When the link to the authenticated page is embedded inside the Word document, and user ctrl+clicks it, Word apparently starts MSIE to get the page. However, in this special case MSIE does not display the login form after getting the 403 status, but reports the error to its caller (MS Word) instead. So Word displays a generic error pop-up to the user, without the user being able to log in.
What to do now? The problem is clearly in the HTTP status code 403, and in its
mis-interpretation by some clients. I don't want to return the login form
in a 200 OK response, because I need e.g. the web crawlers to know that this
is not actually the page they tried to access. As for Symbian, they can be
clearly identified by their User-Agent string, so I can
return 200 OK only for them. But as for MS Word, I have no clue: what I see
is the request made by MSIE (and again, I probably don't want to return
200 OK to every unauthenticated MSIE request).
Any other suggestions, my dear lazyweb?
2 replies for this story:
Adelton wrote:
I'm not sure about that 403: "Authorization will not help and the request SHOULD NOT be repeated". Since you are using cookies for something it's not technically supposed to be used (authentication), I wouldn't worry about that 200 that much. I'd either make it 200 or 302 to some login page, ideally with some Pragma: no-cache so that spiders don't index/cache it.
Yenya wrote: Re: Adelton
Well, the request after 403 is not repeated (by the browser itself). Apache2::AuthCookie returns a login form in that request, and the action of this form is some different URL (which, by coincidence, returns 302 to the original URL, if correct credentials are submitted). So I still think 403 is a perfectly legal way of returning the login form.