This configuration is valid and, when we click the Sign In button, a request is issued to http://someserver.net/auth/sign_in according to the Chrome dev tools. Note how :80 is now omitted (being redundant).
Problem is, when response comes back and goes thru the modified fetch, it is compared with the original API URL (including :80) and comparison fails. This results in a 401 error.
// fetch.js:49-53
function updateAuthCredentials(resp) {
// check config apiUrl matches the current response url
if (isApiRequest(resp.url)) { // <<<< WILL RETURN FALSE
// set header for each key in `tokenFormat` config
var newHeaders = {};
...
// fetch.js:12-14
var isApiRequest = function(url) {
// url = 'http://someserver.net/auth/sign_in
// getApiUrl(...) = 'http://someserver.net:80'
return (url.match(getApiUrl(getSessionEndpointKey()))); // no match!
};
A possible solution would be to make the URL comparison in isApiRequest slightly smarter (capable of handling missing port number if it's 80).
As a workaround we ended up modifying our environment-dependent API URL generation code so that port number is omitted if it's 80.
Hey, in my workplace we just ran into the following GOTCHA:
our production API runs on heroku on
http://someserver.net:80
so here's ourconfigure
:This configuration is valid and, when we click the Sign In button, a request is issued to
http://someserver.net/auth/sign_in
according to the Chrome dev tools. Note how :80 is now omitted (being redundant).Problem is, when response comes back and goes thru the modified
fetch
, it is compared with the original API URL (including:80
) and comparison fails. This results in a 401 error.A possible solution would be to make the URL comparison in
isApiRequest
slightly smarter (capable of handling missing port number if it's 80).As a workaround we ended up modifying our environment-dependent API URL generation code so that port number is omitted if it's 80.
HTH