ADMIRAL with Safari and IE

From ImageWeb

Contents 1 Accessing dataset manifest from Databank for display 2 Further investigations: Safari vs Firefox

Accessing dataset manifest from Databank for display

When submitting a dataset, or viewing the content of a dataset, we find:

(a) using firefox, it mostly works

(b) using Safari, we get a 403 error when retrieving the manifest for the dataset from the Databank service

(c) using IE, similar to Safari

The HTTP request concerned is issued by the web browser Ajax code, and is proxied via the ADMIRAL Apache server and forwarded to the Databank server.

This is the AJAX request under investigation:

       jQuery.ajax({
           type:         "GET",
           url:          dataseturl,
           username:     "admiral",
           password:     "admiral",
           dataType:     "json",
           beforeSend:   function (xhr)
               {
                   xhr.setRequestHeader("Accept", "text/plain");
               },
           success:      function (data, status, xhr)
               {  
                  var datasets = [];
                  for (var name in data)
                  {          
                     datasets.push({ datasetname: name });                
                  }
                  callback(datasets);
               },
           error:        function (xhr, status) 
               { 
                   jQuery("#pageLoadStatus").text("HTTP GET "+ "/admiral-test/datasets"+" failed: "+status+"; HTTP status: "+xhr.status+" "+xhr.statusText);
                   jQuery("#pageLoadStatus").addClass('error');
               },
           cache:        false
       });

When accessing the page directly via the proxied path (i.e. using a URI entered into the browser address bar), safari is able to retrieve the page.

Similar results to these cases can be seen using curl with and without the -u option (i.e. including or not including user credentials).

Hypothesis: Firefox is including credentials with the AJAX request based on previously available values. But when Safari (or IE) processes an AJAX request, these credentials are not included. To test this, try adding credentials to the AJAX request, and see if Safari now works. NOT THIS: it turns out that the ajax code includes the credentials in any case, which is another problem

So there is (presumably) something different about how Safari/IE generate credentials, or maybe the https session.

To diagnose further, we need to observe the traffic between the browser and the ADMIRAL server....

(Later)

Enabling a Wireshark decode of the HTTPS traffic, we now see that Firefox includes Authorization headers in AJAX requests, while Safari does not. This adequately explains the discrepancy observed.

Further investigations: Safari vs Firefox

We created a simple stand-alone application HTML page to test the generation of Authorization headers separately from the rest of the ADMIRAL system. We created two versions of this code: one to retrieve a dataset listing from Databank, the other to retrieve a dataset manifest. (We have been experiencing problems with retrieving the manifest, but not the listing.)

All tests were performed by loading the test pages from the ADMIRAL server, and using Apache proxy configuration to forward requests to the databank server.

(See: http://code.google.com/p/admiral-jiscmrd/source/browse/#hg%2Fspike%2Fajaxcode).

Tests performed using Firefox:

1. Retrieving the manifest (/admiral-test/datasets/DatasetsSubdir), returns "403 Forbidden" response.
2. Retrieving the listing of datasets (/admiral-test/datasets), returns 200 and expected result.
3. Accessing the dataset manifest manually, then retrieving the manifest (/admiral-test/datasets/DatasetsSubdir), returns 200 and expected data

Tests performed using Safari:

1. Retrieving the manifest (/admiral-test/datasets/DatasetsSubdir), returns "403 Forbidden" response.
2. Retrieving the listing of datasets (/admiral-test/datasets), returns 200 and expected result.
3. Accessing the dataset manifest manually, then retrieving the manifest (/admiral-test/datasets/DatasetsSubdir), still returns 403 forbidden.

Comparing the successful Firefox requests with the failed safari request, the only significant different is the presence of an Authorization: header in the request. Safari is not sending this, even though the Javascript Ajax call is providing credentials. Other minor differences in Accept: headers were eliminated by tests that changed these without changing the end results.

So we are seeing different behaviour between different browsers, but also between different pages. Safari works for one page but not the other.

We did uncover an Apache proxy configuration problem that meant that Safari was requesting ADMIRAL server credentials when accessing the Databank server, which could cause problems for Firefox but which was not significantly affecting the Safari tests.

We also noticed that successful Safari requests followed this pattern:

    GET /admiral-test/datasets?_=1296823578707 HTTP/1.1 
    HTTP/1.1 401 Unauthorized  (text/html)
    GET /admiral-test/datasets?_=1296823578707 HTTP/1.1 
    HTTP/1.1 200 OK  (application/json)HTTP/1.1 200 OK  (application/json)

but the failed ones looked like this:

    GET /admiral-test/datasets/DatasetsSubDir?_=1296823666197 HTTP/1.1 
    HTTP/1.1 403 Forbidden  (text/html)

Thus, it seems that Safari sends an Authentication header only on receipt of an HTTP 401 response, but Firefox sends one whenever it has use credentials available. This coupled with the different server behaviour in response to the different requests seems to adequately explain the behaviour we are observing.