Zusätzliche HTTP-Anfrageheader hinzufügen

Pavol Drotar

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 Header mit Ausnahme von ursprungsübergreifenden Headern mit Ausnahme der ursprungsübergreifenden genehmigten, da diese 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:

Tabelle 1: Filtern von CORS-Headern, die nicht auf der Genehmigungsliste 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. Weitere Informationen zum Code finden Sie unter Zusätzliche Header zu benutzerdefinierten Tab-Intents hinzufügen.

Hintergrund

CORS-Anfrageheader auf der Zulassungsliste und nicht auf der Zulassungsliste

Mit Cross-Origin Resource Sharing (CORS) kann eine Webanwendung Ressourcen unterschiedlichen Ursprungs anfordern. Die Liste der von CORS genehmigten Header wird im HTML-Standard geführt. In der folgenden Tabelle sind Beispiele für Überschriften in der Zulassungsliste aufgeführt:

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:

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. Benutzerdefinierte Tab-Intents 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 hinzufügen. 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, besteht darin, zuerst die ursprungsübergreifende Verbindung mithilfe eines digitalen Zugriffslinks zu prüfen. Im nächsten Abschnitt erfahren Sie, wie Sie diese einrichten und einen Intent für benutzerdefinierte Tabs mit den erforderlichen Headern 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 dem offiziellen Leitfaden, um einen Link für digitale 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 den Intent und fügen Sie zusätzliche Header 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 bestätigen, dass die App und die Webanwendung denselben Ursprung haben. Die Überprüfung ist nur erfolgreich, wenn die Digital Asset Links korrekt eingerichtet wurden.

Wir empfehlen, 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

CustomTabsCallback wurde an die Sitzung übergeben. Wir haben die onRelationshipValidationResult() so eingerichtet, dass die zuvor erstellte CustomTabsIntent gestartet wird, sobald die Ursprungsbestätigung abgeschlossen ist.

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. Das Binden und Aufheben der Bindung erfolgt in der Regel in den Methoden des Aktivitätslebenszyklus onStart() und onStop().

// 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 desselben Ursprungs zulässig, was durch einen Link zu einem digitalen Asset bestätigt wird.