Https requests with Authorization not working via

2020-02-28 00:16发布

问题:

Context

XHR requests with Authorization header over HTTPS (both together) don't reach the server, using Safari (IOS and MacOS). But it works with IE, Chrome and Firefox.

I use a valid certificate generated by Letsencrypt and browsers don't display warnings about it.

On the web inspector of Safari, these XHRs try to get result until timeout and no errors displayed.

I have one domain and no sub-domain.

Test

  • Authorization header + HTTPS => Not working
  • Authorization header + No HTTPS (HTTP) => Works
  • No authorization header + HTTPS => Works

Code

I use an interceptor to set authorization header.

this.request = (config) => {
    config.headers = config.headers || {};
    var authData = localStorageService.get('authorizationData');
    if (authData && config.url && !config.url.endsWith("/token")) {
        config.headers = {
            "Authorization": 'Bearer ' + authData.access_token
        };
        config.withCredentials = true;
    }
    return config;
}

Has anyone encountered the same problems ?

UPDATE 1

There is something wrong with Safari + HTTPS + "Authorization" header. If I rename "Authorization" by "MyHeader", and doing some modification on server to retrieve my bearer token with "MyHeader" token, everything works well.

Is "Authorization" header a protected word using HTTPS on safari ?

回答1:

I also faced a similar problem with safari where 'Authorization' in the header was not sent in the GET request but it ended up in a simple thing.

I simply appended a '/' at the end of the request URL and it worked for me.

for eg: change URL from '/token' to '/token/'.



回答2:

When an HTTP request made via safari is made to any url contains words like login, token, etc... safari automatically adds Accept-Encoding header that brokes al



回答3:

To solve that you need access to the device that are running the code and change a safari setting that prevent cross-site tracking, this works fine for me.



回答4:

In my case, using Laravel, it was just the slash removed by .htaccess. When there is an redirect, by obvious reasons, the headers not are forwarded.