: Should I return a http 401 status code on an html based login form? Should I return a http 401 status code on an html based login form? The page is a dedicated login form, and does not

@Carla537

As you note, RFC 2616 requires that a 401 response be accompanied by an RFC 2617 WWW-Authenticate header. I suppose you could technically comply with that requirement by sending a bogus header like:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"


but I have no idea what browsers will do if presented with a 401 response containing no challenges they understand. I would assume that most if not all of them would present the request body to the user (as RFC 2616 says they should do if authentication fails), but neither RFC seems to say so explicitly, so they might legitimately just show a generic error message instead.

A possible alternative (if you don't want to just use a 200 response like everyone else seems to do) would be to use a 403 Forbidden status code. This is a widely used response code, and as far as I know, almost all interactive user agents (i.e. browsers, as opposed to, say, search engines or download managers) should react to it by presenting the content to the user, at least if it's long enough.

Although the description of the 403 status code says that "[a]uthorization will not help", this should IMO be understood in context as referring to RFC 2617 authentication or similar protocol-level authorization mechanisms; as far as the browser is concerned, it has no idea whether submitting a form and receiving a cookie in response counts as "authorization" or something else.

One more commonly used mechanism would be to respond to unauthenticated requests with a temporary redirect to a separate login page, with the original URL passed as a parameter so that the user can be redirected back to it after successful authentication. However, note that a naive implementation could allow a malicious person to craft a login link that would redirect the user to an arbitrary URL after logging in. If this could be a security issue, you should take steps to prevent it, e.g. by only accepting return URLs matching a known safe pattern, or by protecting the return URL with a message authentication code to prevent modification.

In any case, if you're using HTTP cookies to store authentication tokens after login, you should include a Vary header in your responses (both before and after authentication) to prevent inappropriate caching, as in Vary: Cookie.

Vote Up Vote Down

@Jamie184

First, if the page need login, then you probably should block it by robots.txt

Second, if robots do reach the page, a 401 error is proper.

Vote Up Vote Down