I am looking at the digest-fetch.js over the fetch API, and I am finding some problems. The issue is that in my scenario a POST call is made, responded first with 401 with the challenge and then retried with the authentication header, then succeeds. So far, so good.
But our server responds deliberately with 303, giving a different URI (on same server) to pick up the final result.
The fetch API does not allow me to manually handle the redirect (which I totally don't get why this would be considered "insecure" and hence hidden) but when the core fetch API will retry that, it gets a 401 again from our server. At that point it will fail.
I think this is because the fetch API re-uses the headers, namely the Authorization header, as a constant string. That same header is used for the follow-up GET request on the 303 redirection. The server barks that the nc has not been increased.
As [https://en.wikipedia.org/wiki/Digest_access_authentication] says:
[...] the client may make another request, reusing the server nonce value (the server only issues a new nonce for each "401" response) but providing a new client nonce (cnonce). For subsequent requests, the hexadecimal request counter (nc) must be greater than the last value it used [...]
I consider this a bug in digest-fetch but worse in the Fetch API (of Chrome and Firefox anyway).
I have tried not to provide a String header, but an object with a toString method, hoping that this would be called every time a request is made. So, instead of:
options.headers.Authorization = digest;
I did:
options.headers.Authorization = {
toString: function() {
alert(new Error("Gotcha! " + digest));
return digest;
}
}
Yet sadly, that gets called only once. I think out of the core fetch API function, where I am afraid a string is stored, and the toString() method will not again be called.
Any workaround this problem?