KontextHTTPS-Anfragen mit Autorisierung nicht über Safari Arbeits
XHR-Anfragen mit Authorization-Header über HTTPS (beide zusammen) erreicht nicht den Server, mit Safari (IOS und MacOS). Aber es funktioniert mit IE, Chrome und Firefox.
Ich verwende ein gültiges Zertifikat, das von Letsencrypt generiert wurde, und Browser zeigen keine Warnungen darüber an.
Im Webinspektor von Safari versuchen diese XHRs, bis zum Timeout Ergebnisse zu erhalten, und es werden keine Fehler angezeigt.
Ich habe eine Domain und keine Subdomain.
-Test
- Authorization-Header + HTTPS => Ein Problem
- Authorization-Header + Keine HTTPS (HTTP) => Works
- Keine Berechtigung Header + HTTPS => Funktioniert
Code
Ich benutze einen Interceptor, um Autorisierungsheader zu setzen.
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;
}
Hat jemand die gleichen Probleme festgestellt?
UPDATE 1
ist es etwas falsch mit Safari + HTTPS + "Autorisierung" Header. Wenn ich "Authorization" durch "MyHeader" umbenenne und einige Änderungen am Server vornimmt, um mein Bearer-Token mit dem "MyHeader" -Token abzurufen, funktioniert alles gut.
Ist der Header "Autorisierung" ein geschütztes Wort mit HTTPS auf Safari?
Haben Sie jemals festgestellt, ob Authorization ein geschütztes Wort in Safari ist? –
Ich habe nichts über geschützte Wörter auf Safari gefunden. –
Wir haben entdeckt, was das Problem für uns war. Wenn Sie versuchen, Safari auf einem unsicheren Zertifikat zu verwenden (selbstsigniert war der Schuldige für uns), dann erlaubt Ihnen Safari nicht, das Autorisierungskopfzeilenfeld zu manipulieren. Unsere Lösung bestand darin, entweder dem selbstsignierten Zertifikat zu vertrauen oder auf normales http zu wechseln (beide Lösungen funktionierten). Klingt für mich, dass Ihr Problem anders war, obwohl –