2

I'm making CORS requests between my web application and a server. The request is a simple authorization request. The request is sent, the server sets a "JSESSIONID" cookie, a dialogue box pops up, you type your username and password and then press submit. The httpRequest then completes once the credentials are correct, and the response header sets a "LWSSO_COOKIE_KEY" cookie for the client to use for access.

The problem is that this is working flawlessly in internet explorer, and not in chrome or firefox.

Here's my request code:

// code snippet from : http://www.html5rocks.com/en/tutorials/cors/
// Create the XHR object.
function createCORSRequest(method, url) {
    console.log("createCORSRequest: ");
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr) {
      // XHR for Chrome/Firefox/Opera/Safari.
      xhr.open(method, url, true);
      xhr.withCredentials = true;   
    } else if (typeof XDomainRequest != "undefined") {
      // XDomainRequest for IE.
      xhr = new XDomainRequest();
      xhr.open(method, url, false);
    } else {
      // CORS not supported.
      xhr = null;
    }
    return xhr;
}

// Make the actual CORS request.
function makeCorsRequest(action,URL) {
    console.log("makeCorsRequest action: "+action+"; URL: "+URL);
    var xhr = createCORSRequest(action, URL);
    if (!xhr) {
        console.log('CORS not supported');
        return;
    }
    // Response handlers.
    xhr.onload = function() {
        var text = xhr.responseText;
        console.log('Response text from CORS request to ' + URL + ': ' + text);
    };

    xhr.onerror = function() {
        console.log('Woops, there was an error making the request.');
    };

    xhr.send();
    return xhr;
}

Issue with firefox is this error: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://someIP:somePort/qcbin/authentication-point/authenticate. (Reason: CORS header 'Access-Control-Allow-Origin' missing)."

The weird part about this is that the authentication http request responds with status 200, and a set cookie header for the "LWSSO_COOKIE_KEY", but then calls the "onerror" handler from makeCorsRequest(action,URL).

headers and cookies from firefox: This header the server responds by setting the JSESSIONID cookie enter image description here setting the JSESSIONID cookie enter image description here After submitting my username and password the server responds by setting the JWSSO_COOKIE_KEY: enter image description here setting the JWSSO_COOKIE_KEY: enter image description here

Lastly here's the console output: enter image description here

Issue with Chrome is identical to firefox's behavior. Why does this http request work in Internet explorer but not chrome and firefox?

Here's what the headers and cookies look like in IE (11): Request header: enter image description here Response header: enter image description here Cookies: enter image description here Console: enter image description here Once again. This is identical code used for all these results, but I'm experiencing different behavior in chrome and firefox than in Internet Explorer.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Evan Stenger
  • 91
  • 4
  • 9
  • Is the server not sending an [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Allow-Origin) header? The [screenshot of the response headers in devtools](http://i.stack.imgur.com/OQgBI.png) seems to indicate that it’s not sending Access-Control-Allow-Origin. And in that case, the behavior you’re seeing in Chrome and Firefox is the expected behavior, and the question would be why IE not enforcing CORS for that document. – sideshowbarker Oct 02 '15 at 19:01
  • Exactly, that's why I'm really confused. Because the server does not appear to be sending Access-Control-Allow-Origin from everything I've seen, but the response in IE does not follow suit. I'm able to send the authentication and pull data from the server no problem in IE. – Evan Stenger Oct 02 '15 at 19:04
  • That would seem to be a bug in IE then. It’s a bit surprising to hear that it’s doing that, unless it’s somehow considering the requesting origin and the requested origin to be the same, or has the requesting origin in some kind of whitelist or something. – sideshowbarker Oct 02 '15 at 19:08
  • @sideshowbarker : I know that this site would not exist in a whitelist of any kind. This is a brand new site that I created at work to interface with an existing application https://en.wikipedia.org/wiki/HP_Application_Lifecycle_Management HP ALM. Whoever is in charge of the server with the HP ALM application has no idea that this app exists, I'm just using the app's rest API. – Evan Stenger Oct 02 '15 at 19:15
  • 2
    Are you sure the servers are not in the "Intranet Zone" according to IE? See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#IE_Exceptions – Chris Thornhill Oct 03 '15 at 02:09
  • Now that you mention it, the ALM application I'm trying to communicate is on the Intranet. I had not considered this till you brought it up @ChrisThornhill . The URL is something like http://hp_alm.AA.XYYXYX.com:PORT#/qcbin/start_a.jsp. Does this mean that only IE makes this exception, and therefore I cannot execute the same type of request on Firefox or Chrome? I also have the option of using CloudCode, but I'm not entirely sure how those requests would work. The server that the CloudCode would be on is not the same as the ALM application. So I'm assuming I'd have the same issues. – Evan Stenger Oct 03 '15 at 02:21
  • As far as I know, Firefox and Chrome do not have awareness of, or support for doing anything with, the Windows "Intranet Zone" that IE behavior can change in relation to. Instead CORS is in (large) part intended to be a sorta standard cross-browser/platform way to achieve some of the same effect. So you really need to deploy CORS for this if you want it to work at all for Firefox, Chrome, etc. users. – sideshowbarker Oct 03 '15 at 04:25
  • So it sounds like I would have to do some work on the ALM server side to get it to work with my web application? @sideshowbarker – Evan Stenger Oct 03 '15 at 14:13
  • Yeah, it definitely requires some server-side config. If you run into problems with that config, that would be something you’d want to open a new question for. – sideshowbarker Oct 03 '15 at 14:25
  • Ok, well unfortunately for me I have no control over the ALM server at work. I guess I'll make a routine to run only in IE to pull all the necessary data into my web app's server. @sideshowbarker – Evan Stenger Oct 03 '15 at 14:29
  • 1
    Another option is to use a local reverse proxy to make it appear to your browser that all services are from the same origin. For instance, have your proxy listen on localhost:8080, and forward /CSCRMpageNBproj to localhost:8383/CSCRMpageNBproj, and /qcbin to hp_alm.AA.XYYXYX.com:PORT#/qcbin/. I routinely do this using Apache on Windows when developing UIs. Here's one HOWTO: http://www.microhowto.info/howto/configure_apache_as_a_reverse_proxy.html – Chris Thornhill Oct 03 '15 at 14:42
  • I'll give that a try. Thanks for the help everyone! It's just nice to know that there is a reason for this behavior. – Evan Stenger Oct 03 '15 at 18:22

0 Answers0