HTTP 401 - what's an appropriate WWW-Authenticate header value?

Will Morgan picture Will Morgan · Nov 17, 2009 · Viewed 123.8k times · Source

The application I'm working on at the moment has a session timeout value. If the user hasn't interacted for longer than this value, the next page they try to load, they will be prompted to log in.

All requests made are routed through this mechanism, which includes AJAX calls. Originally we were sending a 200 header with the login page, which introduces some problems with AJAX since code is run if a 200 response is sent, and most data sent back from these RPC calls is JSON or raw JavaScript that gets evaluated (don't ask :|).

I've suggested that a 401 is better, since our JSON parser won't try to consume an HTML login page.. :)

When reading the spec, however, I noticed that the WWW-Authenticate field must also be sent.

What is a good value for this field? Will Application Login suffice?

Answer

Swanny picture Swanny · Nov 17, 2009

When indicating HTTP Basic Authentication we return something like:

WWW-Authenticate: Basic realm="myRealm"

Whereas Basic is the scheme and the remainder is very much dependent on that scheme. In this case realm just provides the browser a literal that can be displayed to the user when prompting for the user id and password.

You're obviously not using Basic however since there is no point having session expiry when Basic Auth is used. I assume you're using some form of Forms based authentication.

From recollection, Windows Challenge Response uses a different scheme and different arguments.

The trick is that it's up to the browser to determine what schemes it supports and how it responds to them.

My gut feel if you are using forms based authentication is to stay with the 200 + relogin page but add a custom header that the browser will ignore but your AJAX can identify.

For a really good User + AJAX experience, get the script to hang on to the AJAX request that found the session expired, fire off a relogin request via a popup, and on success, resubmit the original AJAX request and carry on as normal.

Avoid the cheat that just gets the script to hit the site every 5 mins to keep the session alive cause that just defeats the point of session expiry.

The other alternative is burn the AJAX request but that's a poor user experience.