PhoneGap/Cordova not listening for 401, modifying http response code to 200 not working

Question

CPG = Cordova/PhoneGap

This question is pretty much the result of my earlier question on the PhoneGap/401 bug here: Angular not getting response when it's a non-200

The resolution (at the time) was to implement a timeout on all of the calls. That was fine until this hit production. We realized that the app is being used in spotty areas, and a "timeout" could just be that there wasn't a good enough connection at the time. So, not an acceptable solution for our environment/app.

Since CPG does not "listen" for a 401 response code, I thought that maybe I could just change the response code that's coming back to something that we KNOW CPG listens for, and then just modify the message body and process accordingly.

So, we applied at our Gateway (Firewall -> LoadBalancer -> Gateway (where AD authentication occurs) -> Service) level, the process of modifying all 401 responses to return a 200 status code, with message "Authentication Failed", or something like that.

First test was to check and make sure that we get the response correctly via Fiddler. All is well. Next, when checking in ou CPG application (running AngularJS), we STILL never receive ANY response. I'm able to see in Fiddler that EVERY TIME the service gets called with invalid credentials, it returns a response within 500 milliseconds. Though, we NEVER receive it in the app.

Is there another header or something that could be blocking this? In Fiddler, the 200 response is very basic. I read this google forums post about the 'www-Authenticate' header is the cause of CPG not getting (processing) the response, but that's if it was coming back in a 401, not a 200.

Why is this not getting picked up by CPG?

Here's the code, not that it will help that much...

$http.defaults.headers.common.Authorization = 'Basic ' + $rootScope.basicAuth;

$http({
    method: "POST",
    url: url,
    data: {
        "Username": user,
        "Password": password,
        "AccessToken": ""
    },
    headers: { "Content-Type": "application/json",
    "Accept-Encoding": "gzip" },
    timeout: 10000
})
.success(function (data, status, headers, config) {
    if (data.IsAuthenticated) {
        deferred.resolve(true);
        session.setSession();
    } else {
        //deferred.reject(status); // This is always a 200, so let's return a generic message
        window.logger.logIt("Status: " + status + "; Data: " + data);
        deferred.reject("Authentication Failed");
    }
})
.error(function (data, status, headers, config) {
    window.logger.logIt("status: " + status);
    deferred.reject("Authentication Failed");
});

Edit:

Found this bug/issue on the CPG site. The last comment mentions that just removing the 'WWW-Authenticate' header SHOULD fix the issue. But I've tried that implementation also and it didn't work for me either. https://issues.apache.org/jira/browse/CB-2415

Answer 1

You can't always expect a server to be configurable. Specially when you're making an app for 3rd party clients. Can't tell everyone "Hey, please remove the WWW-Authenticate Header to use my app". Doesn't work that way.

Answer 2

Well, this is pretty embarassing (don't know why I'm not just deleting the question...)

The above DOES work, if you call the correct url...

My server/network guy configured these changes for our path https://asdfasdfasfd.asdfasdf/asdfsadf/asfdsafd

BUT, I was pointing my environment to http://asdfasdfasfd.asdfasdf/asdfsadf/asfdsafd (I did not have the s in https://).

After fixing that, I was then able to receive a 200 and process accordingly.

But, that made me want to test the removal of the WWW-Authenticate header to if that got fixed also. Yep, it sure did.

The fix for getting 401's back in a CPG/iOS application is to remove the WWW-Authenticate header.