views:

255

answers:

2

Hi,

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?

+2  A: 

No, you'll have to specify the authentication method to use (typically "Basic") and the authentication realm. See http://en.wikipedia.org/wiki/Basic%5Faccess%5Fauthentication for an example request and response.

You might also want to read RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication.

Pär Wieslander
+1  A: 

When indicating HTTP Basic Authentication we return something like:

WWW-Authenticate: Basic realm="myRealm"

where as 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.

Your obviously not using Basic however since you there is no point having session expiry when Basic Auth is used. I assume your 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 usually 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.

Swanny
Thanks mate, I'm now using a 403 instead since it isn't a redirect and it literally includes the login form in place of the original page. It also better matches the W3 specification.Thanks for the information however.
Will Morgan

related questions