In dieser Anleitung erfahren Sie, wie Sie häufig auftretende Probleme im Browser-Konsolenfenster im Zusammenhang mit der Fehlermeldung Access-Control-Allow-Origin beheben können. Im Folgenden finden Sie Beispiele für Fehlermeldungen. 

  • Fehler beim Laden Kein Header „Access-Control-Allow-Origin“
  • Cross-Origin-Anfrage blockiert: Die Richtlinie „Gleiche Herkunft“ verhindert das Lesen der Remote -Ressource ... Grund: CORS-Header „Access-Control-Allow-Origin“ fehlt
  • Fehler beim Laden Antwort auf Preflight-Anfrage besteht keine Zugriffskontrollprüfung: Kein Header „Access-Control-Allow-Origin“ in der angeforderten Ressource vorhanden. Origin ... hat daher keinen Zugriff

Dieser Beitrag enthält die folgenden Themen.

  • Fragen zur Fehlerbehebung
  • Mögliche nächste Schritte

Fehlerursachen

Eine browserbasierte Webanwendung (möglicherweise eine Apps-Framework-App) versucht, einen „Cross-Origin“-Aufruf zu tätigen, um eine „Shared Resource“ (geteilte Ressource) von einem externen Webdienst abzurufen. Das wird als „CORS“-Anfrage (Cross-Origin-Resource-Sharing) bezeichnet.

Es gibt einen browserbasierten CORS-Standard, der solche ursprungsübergreifenden Aufrufe verwaltet. Wenn bestimmte Bedingungen nicht erfüllt sind, können Fehler auftreten.

Dies ist nicht unbedingt ein Fehler, da es sich um einen Anwendungsfall handeln kann, der von der Webanwendung des Benutzers und dem externen Remote-Dienst absichtlich nicht zugelassen wird.

Wenn ein Ursprung (www.ursprung1.com) einen anderen Ursprung (www.ursprung2.com) abruft, wird das als ursprungsübergreifende Anfrage bezeichnet. Damit diese Anfrage funktioniert, müssen bestimmte Bedingungen erfüllt sein. Der aufgerufene externe Service (www.origin2.com) muss den HTTP -Header zurückgeben Access-Control-Allow-Origin in seiner Antwort.

Wenn der externe Dienst diesen Header nicht zurückgibt, wird die Anforderung durch die Einhaltung der CORS-Spezifikation durch den Browser gestoppt und einer der obigen Fehler zurückgegeben.

Fragen zur Fehlerbehebung

  • Wie lautet die Start-URL des Aufrufs (d. h. der Ursprung)?
    Diese ist manchmal in der Fehlermeldung selbst zu finden.
  • Wie heißt die URL des externen Dienstes, der abgerufen wird?
    Diese ist manchmal in der Fehlermeldung der Konsole zu finden.
  • Was wird abgerufen und warum? Handelt es sich um eine PNG-Datei? Ein Skript, CSS oder eine Schriftartdatei? Was genau wird abgerufen und wofür wird es verwendet?
    Das kann Aufschluss über den Anwendungsfall geben und zeigen, warum das Asset an diesem Remote-Standort so wichtig ist.
  • Ist für diese externe Ressource eine Authentifizierung erforderlich?
    Wenn eine Weiterleitung erforderlich ist, wird derAccess-Control-Allow-Origin Antwortheader möglicherweise nicht zurückgegeben und der Aufruf schlägt fehl. Kopieren Sie die URL der Ressource direkt in eine neue Inkognito-Registerkarte im Browser. Dies kann ein guter Test dafür sein, ob unter allgemeinen Umständen darauf zugegriffen werden kann, ist aber keine Garantie dafür, dass es im Code der Web-App funktionieren wird.
  • Können Sie den HTTP-Methodenaufruf OPTIONS in der Registerkarte „Network“ des Browsers sehen?
    Wenn in der ursprungsübergreifenden Anfrage angepasste Anforderungsheader, Authentifizierungs- oder andere Bedingungen vorhanden sind, führt der Browser einen zusätzlichen HTTP-Aufruf durch. Das wird auch als „Preflight-Aufruf“ bezeichnet. Im Code der Web-App ist dies nicht explizit angegeben. Der Browser im Hintergrund erstellt und macht es zu einem Teil der CORS -Spezifikation.
    Wenn dieser OPTIONS-Aufruf erfolgt, müssen bestimmte Werte in der Antwort dieses Aufrufs enthalten sein, damit er erfolgreich ist und der eigentliche HTTP-Aufruf für die Ressource erfolgt. Wenn der Aufruf von OPTIONS fehlschlägt, wird die Ressource nicht abgerufen und in der Browserkonsole erscheint ein CORS-Fehler. Notieren Sie sich, wenn Sie einen OPTIONS-Anruf sehen. Notieren Sie sich außerdem, ob ein Aufruf mit Weiterleitung (Status 302) unmittelbar vor dem OPTIONS-Aufruf stattfindet. Wenn bei einem OPTIONS-Aufruf eine Weiterleitung stattfindet, schlägt der OPTIONS-Aufruf höchstwahrscheinlich fehl. Das bedeutet, dass der Aufruf der Ressource ebenfalls fehlschlägt und einen CORS-Fehler auslöst.
  • Was ist ein Anwendungsfall für die Bereitstellung externer Ressourcen?
    Finden Sie heraus, warum diese externe Ressource überhaupt abgerufen wird. Das kann bei Lösungsansätzen oder Änderungen wichtig sein.
  • Generieren Sie eine HAR-Datei.
    Wenn Sie eine Momentaufnahme des fehlgeschlagenen Aufrufs und der Ereignisse davor und danach erhalten, können Sie das Problem besser beheben und vermeiden, dass der Benutzer es reproduzieren muss. Header in Anfragen und Antworten können zusammen mit OPTIONS-Aufrufen und -Weiterleitungen untersucht werden.

Mögliche nächste Schritte

  • Wem gehört der externe Server? Vielleicht kann der Server dahingehend modifiziert werden, dass er die CORS-Spezifikation einhält, um die Access-Control-Allow-Origin-Kopfzeile zurückzugeben. Aber selbst wenn der Server etwas ist, das intern kontrolliert wird, ist das nicht unbedingt ein Allheilmittel. Es kann gute Gründe geben, dass ein bestimmter externer Dienst eine Ressource nicht teilen möchte. Wenn der externe Server nicht intern gesteuert wird, sollten Sie mit dem betreffenden Anbieter zusammenarbeiten oder einen anderen Lösungsweg entwickeln, wenn der Anwendungsfall als gültig betrachtet wird.
  • Wird die App mit dem Zendesk Apps Framework geschrieben? Ein Backend-Proxyserver ist über den Aufruf client.request() verfügbar. Um diesen Proxy zu verwenden, legen Sie cors:false in den Einstellungen für client.request fest. Beachten Sie, dass „false“ auch der Standardwert der Einstellung ist. Da es sich bei dem Proxyservice um einen Backend-Service handelt, muss er nicht die browserbasierte CORS-Spezifikation einhalten, sodass der ursprungsübergreifende Aufruf möglicherweise erfolgreich über den Proxy erfolgt.
    Auch das ist nicht immer ein Allheilmittel. Der Proxyservice unterstützt nicht das Abrufen von Binärdateien oder binären Informationen aus externen Diensten. Es kann auch andere App-spezifische Gründe geben, warum das keine Lösung ist.
  • Kann die Ressource direkt in die Web-App eingebettet werden? Anstatt eine ursprungsübergreifenden Suche nach einer Ressource durchzuführen, sollten Sie sie in die Web-App integrieren. Dadurch wird der ursprungsübergreifende Aufruf (da es sich jetzt um eine lokale Ressource handelt) komplett vermieden und alle CORS-Probleme verschwinden. Das ist jedoch nicht immer möglich. Manchmal sind die URLs externer Ressourcen nicht im Voraus bekannt, oder die Ressource ist zu groß, um sie als lokale Ressource zu verwenden, oder die Ressource wechselt zu oft, um sie als lokale statische Ressource herunterzuladen.
  • Was ist die Browserversion? Obwohl die CORS-Spezifikation ein Standard ist, können die von Browsern zurückgegebenen Fehlermeldungen unterschiedlich sein. Chrome gibt andere Konsolennachrichten zurück als Firefox. 
  • Manchmal gibt es keine Lösung Manchmal ist eine Ressourcenanfrage von einem externen Dienst nicht dazu gedacht, im Kontext einer Browser-Web-App geteilt zu werden. Der Ressourceninhaber entscheidet, ob er die Ressource teilt oder nicht. Das hängt nicht von der Web-App ab. Dieses Verhalten ist möglicherweise erwünscht.

Weitere Informationen finden Sie in den folgenden Ressourcen:

  • Beitrag aus Wikipedia: Ursprungsübergreifende Ressourcennutzung (CORS)
  • Beitrag aus Web.Dev: Ursprungsübergreifende Ressourcennutzung (CORS)
  • Beitrag aus Mozilla: Ursprungsübergreifende Ressourcennutzung (CORS)
  • Beitrag aus Mozilla: OPTIONS
  • Beitrag aus Fetch: Fetch
  • Beitrag aus Fetch: CORS-Protokoll
Powered by Zendesk