HTTP-Anfragen enthalten Header wie „User-Agent“ oder „Content-Type“. Neben den von Browsern angehängten Headern können Android-Apps über das EXTRA_HEADERS Intent-Extra zusätzliche Header wie „Cookie“ oder „Referrer“ hinzufügen. Aus Sicherheitsgründen filtert Chrome einige der zusätzlichen Header je nachdem, wie und wo eine Intent gestartet wird.
Cross-Origin-Anfragen erfordern eine zusätzliche Sicherheitsebene, da der Client und der Server nicht demselben Eigentümer gehören. In diesem Leitfaden wird beschrieben, wie Sie solche Anfragen über benutzerdefinierte Tabs in Chrome starten, also über Intents, die von Apps gestartet werden, die eine URL im Browsertab öffnen. Bis Chrome 83 konnten Entwickler beim Starten eines benutzerdefinierten Tabs beliebige Header hinzufügen. Ab Version 83 filtert Chrome alle ursprungsübergreifenden Header, mit Ausnahme derer, die sich auf der Zulassungsliste befinden, da nicht zugelassene Header ein Sicherheitsrisiko darstellen. Ab Chrome 86 können nicht auf der Zulassungsliste stehende Header an plattformübergreifende Anfragen angehängt werden, wenn der Server und der Client über einen Digital Asset Link verbunden sind. Dieses Verhalten ist in der folgenden Tabelle zusammengefasst:
| Chrome-Version | Zulässige CORS-Header |
|---|---|
| vor Chrome 83 | approvelisted, non-approvelisted |
| Chrome 83 bis Chrome 85 | approvelisted |
| ab Chrome 86 | „approvelisted“ oder „non-approvelisted“, wenn ein Digital Asset Link eingerichtet ist |
Tabelle 1: Filterung von CORS-Headern, die nicht auf der Zulassungsliste stehen.
In diesem Artikel wird beschrieben, wie Sie eine bestätigte Verbindung zwischen dem Server und dem Client einrichten und diese verwenden, um sowohl HTTP-Header mit als auch ohne Zulassungsliste zu senden. Sie können mit dem Code zum Abschnitt Benutzerdefinierten Tab-Intents zusätzliche Header hinzufügen springen.
Hintergrund
CORS-Anfrageheader auf der Zulassungsliste und nicht auf der Zulassungsliste
Mit Cross-Origin Resource Sharing (CORS) kann eine Webanwendung von einer Quelle Ressourcen einer anderen Quelle anfordern. Die Liste der von CORS genehmigten Header wird im HTML-Standard geführt. In der folgenden Tabelle sind Beispiele für Header in der Zulassungsliste aufgeführt:
| Header | Beschreibung |
|---|---|
| accept-language | natürliche Sprachen angibt, die der Kunde versteht |
| content-language | beschreibt die Sprache, die für die aktuelle Zielgruppe bestimmt ist |
| content-type | gibt den Medientyp der Ressource an |
Tabelle 2: Beispiel für CORS-Header auf der Zulassungsliste
Die Header auf der Zulassungsliste gelten als sicher, da sie keine vertraulichen Nutzerinformationen enthalten und es unwahrscheinlich ist, dass der Server dadurch potenziell schädliche Vorgänge ausführt.
Beispiele für nicht auf der Zulassungsliste stehende Header sind in der folgenden Tabelle aufgeführt:
| Header | Beschreibung |
|---|---|
| bearer-token | authentifiziert den Client bei einem Server |
| origin | gibt den Ursprung der Anfrage an |
| Keks | enthält vom Server festgelegte Cookies |
Tabelle 3: Beispiele für nicht auf der Zulassungsliste stehende CORS-Header
Das Anhängen von nicht auf der Zulassungsliste stehenden Headern an CORS-Anfragen wird vom HTML-Standard nicht empfohlen. Außerdem gehen Server davon aus, dass Cross-Origin-Anfragen nur Header auf der Zulassungsliste enthalten. Wenn nicht auf der Zulassungsliste stehende Header von Domains mit unterschiedlichen Ursprüngen gesendet werden, können bösartige Drittanbieter-Apps Header erstellen, die Nutzer-Cookies missbrauchen, die in Chrome (oder einem anderen Browser) gespeichert und an Anfragen angehängt werden. Die Cookies könnten schädliche Servertransaktionen authentifizieren, die andernfalls nicht möglich wären.
CORS-Header auf der Zulassungsliste an Anfragen für benutzerdefinierte Tabs anhängen
Benutzerdefinierte Tabs sind eine spezielle Möglichkeit, Webseiten in einem benutzerdefinierten Browsertab zu öffnen. Intents für benutzerdefinierte Tabs können mit CustomTabsIntent.Builder() erstellt werden. Sie können diesen Intents auch Header mit einem Bundle mit dem Flag Browser.EXTRA_HEADERS anhängen:
CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();
Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));
Wir können CORS-Anfragen für benutzerdefinierte Tabs jederzeit Header aus der genehmigten Liste anhängen. In Chrome werden jedoch standardmäßig Header herausgefiltert, die nicht auf der Zulassungsliste stehen. Andere Browser verhalten sich möglicherweise anders, aber Entwickler sollten davon ausgehen, dass Header, die nicht auf der Zulassungsliste stehen, generell blockiert werden.
Die unterstützte Methode zum Einfügen von Headern, die nicht auf der Zulassungsliste stehen, in benutzerdefinierten Tabs besteht darin, zuerst die plattformübergreifende Verbindung mithilfe eines Digital Asset Links zu bestätigen. Im nächsten Abschnitt erfahren Sie, wie Sie diese einrichten und einen Intent für benutzerdefinierte Tabs mit den erforderlichen Überschriften starten.
Benutzerdefinierten Tab-Intents zusätzliche Header hinzufügen
Digital Asset Links einrichten
Damit nicht auf der Zulassungsliste stehende Header über Intents für benutzerdefinierte Tabs übergeben werden können, muss eine digitale Asset-Verknüpfung zwischen der Android- und der Webanwendung eingerichtet werden, die bestätigt, dass der Autor Inhaber beider Anwendungen ist.
Folgen Sie der offiziellen Anleitung, um einen Link zu digitalen Assets einzurichten. Verwenden Sie für die Linkbeziehung „delegate_permission/common.use_as_origin“, was angibt, dass beide Apps nach der Bestätigung des Links zum selben Ursprung gehören.
Intent für benutzerdefinierten Tab mit zusätzlichen Headern erstellen
Es gibt mehrere Möglichkeiten, einen Intent für benutzerdefinierte Tabs zu erstellen. Sie können den in androidX verfügbaren Builder verwenden, indem Sie die Bibliothek den Build-Abhängigkeiten hinzufügen:
MULTI_LINE_CODE_PLACEHOLDER_1
Erstellen Sie die Intent-Definition und fügen Sie zusätzliche Überschriften hinzu:
MULTI_LINE_CODE_PLACEHOLDER_2
Verbindung für benutzerdefinierte Tabs einrichten, um den Asset-Link zu validieren
Eine Verbindung für benutzerdefinierte Tabs wird verwendet, um eine CustomTabsSession zwischen der App und dem Chrome-Tab einzurichten. Wir benötigen die Sitzung, um zu prüfen, ob die App und die Webanwendung zum selben Ursprung gehören.
Die Überprüfung ist nur erfolgreich, wenn die Digital Asset Links korrekt eingerichtet wurden.
Wir empfehlen Ihnen, CustomTabsClient.warmup() anzurufen. So kann die Browseranwendung im Hintergrund vorab initialisiert und das Öffnen der URL beschleunigt werden.
MULTI_LINE_CODE_PLACEHOLDER_3
Callback einrichten, der den Intent nach der Validierung startet
Die CustomTabsCallback wurde an die Sitzung übergeben. Wir haben die onRelationshipValidationResult() so eingerichtet, dass die zuvor erstellte CustomTabsIntent gestartet wird, sobald die Bestätigung des Ursprungs erfolgreich war.
MULTI_LINE_CODE_PLACEHOLDER_4
Dienstverbindung für benutzerdefinierte Tabs binden
Durch die Bindung des Dienstes wird der Dienst gestartet und die onCustomTabsServiceConnected() der Verbindung wird schließlich aufgerufen. Denken Sie daran, die Bindung des Dienstes entsprechend aufzuheben. Die Bindung und Aufhebung der Bindung erfolgt in der Regel in den Methoden onStart() und onStop() des Aktivitätszyklus.
// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
CustomTabsClient.getPackageName(MainActivity.this, null), connection);
// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);
Code der Demoanwendung
Weitere Informationen zum Custom Tabs-Dienst Eine funktionierende Beispiel-App finden Sie im GitHub-Repository android-browser-helper.
Zusammenfassung
In diesem Leitfaden wurde gezeigt, wie benutzerdefinierte Header zu CORS-Anfragen für benutzerdefinierte Tabs hinzugefügt werden. Header auf der Zulassungsliste können jeder CORS-Anfrage für benutzerdefinierte Tabs hinzugefügt werden. Header, die nicht auf der Zulassungsliste stehen, gelten in CORS-Anfragen im Allgemeinen als unsicher und werden von Chrome standardmäßig herausgefiltert. Das Anhängen ist nur für Clients und Server mit demselben Ursprung zulässig, was durch einen Link zu einem digitalen Asset bestätigt wird.