310 Part II: Developing an Ajax Library^
Similar to the logout concern, the Authorization header sometimes gets “stuck.” This
is a problem when trying to log in with the right password after doing so with a wrong one,
when logging out, and when logging into two separate areas of the same site. So far, the
only way we have found around this is closing the browser and starting again, which is
hardly ideal.
Because you have control over requests with Ajax, you might try to manipulate the
Authorization header directly as it is certainly possible to create request headers to send
with the XHR request. We explore such an idea with the example at http://ajaxref.com/ch7/
authenticationheaders.html. The problem we run into here is that when the header is sent, it
gets set for that request but not set for further requests. This causes the built-in pop-up to
appear when the user is redirected to the protected area. The reason the Authorization
header does not stick is because the 401 response was never sent before authorizing the
header, so the browser does not realize that it should hang onto that header value.
The next step is to try to implement the 401 being sent and then sending the request
again with the header. Unfortunately, when the 401 comes back the first time, that XHR
object is complete and the readyState reaches 4, so the browser thinks the final status is
401 and pops up the built-in pop-up.
Finally, you might try to make a single request to grab data from a protected area and
display it on the page. The example found at http://ajaxref.com/ch7/authenticationheader
sdata.html experiments with such an approach. In this example, we directly request the
protected page and create the authentication header ourselves. If the header is correct, it
returns the data and puts it into the current page. However, if it is wrong, the user will get
the pop-up. With all these failures, you should probably take our advice and just accept that
Ajax and HTTP authentication don’t play nicely together for now. Sorry, fans of REST style
architectures, we really need to rely on custom form-based authentication with cookies if
only to preserve programmer sanity.Custom Form-Cookie Authentication
Using cookies to store credentials is much simpler in terms of quirks, but this approach has
its own problems. In order to use this method, we first define a custom form to collect the
username and password. Then the password is encoded using an md5 hash and sent using
the library.var url = "http://ajaxref.com/ch7/protectedsession.php";
var payload = "username=" + username + "&password=" +
AjaxTCR.data.encodeMD5(password);
var options = { method: "GET",
payload : payload,
onSuccess : showResponse};
AjaxTCR.comm.sendRequest(url,options);On the server, the username/hashed password is compared with the stored username/
hashed password and the user is logged in or not. In the example, a simple message is
returned indicating if the request was valid or not.<?php
session_start();