HTTP-Anfragen enthalten Header wie „User-Agent“ oder „Content-Type“. Mit Ausnahme von Headern,
Browser hinzugefügt haben, können Android-Apps zusätzliche Header wie "Cookie" oder "Verweis-URL" über die
EXTRA_HEADERS Absicht – extra. Aus Sicherheitsgründen filtert Chrome einige der zusätzlichen Header heraus.
je nachdem, wie und wo ein Intent
eingeführt wird.
Ursprungsübergreifende Anfragen erfordern eine zusätzliche Sicherheitsebene, da Client und Server nicht derselben Partei gehören. In diesem Leitfaden wird die Einführung solcher Anfragen über Chrome erläutert. benutzerdefinierte Tabs, d.h. Intents, die über Apps gestartet werden, in denen eine URL auf dem Browsertab geöffnet wird. Bis Chrome 83 – Entwickler könnten beim Starten eines benutzerdefinierten Tabs beliebige Header hinzufügen. Ab Version 83 und höher Filterung aller mit Ausnahme von ursprungsübergreifenden Headern mit Ausnahme der gelisteten Zulassungslisten gestartet, da Header, die nicht auf der Zulassungsliste stehen, ein Sicherheitsrisiko darstellte. Ab Chrome 86 ist es möglich, nicht zugelassene Header an ursprungsübergreifende Anfragen, wenn Server und Client über einen Digital Asset Link miteinander verbunden sind Dieses Verhalten ist in der folgenden Tabelle zusammengefasst:
| Chrome-Version | CORS-Header zulässig |
|---|---|
| vor Chrome 83 | auf der Zulassungsliste, nicht auf der Zulassungsliste |
| Chrome 83 bis Chrome 85 | auf der Zulassungsliste |
| ab Chrome 86 | auf der Genehmigungsliste und nicht auf der Zulassungsliste, wenn ein Digital-Asset-Link eingerichtet wird |
Tabelle 1: Filtern von CORS-Headern, die nicht auf der Genehmigungsliste stehen.
In diesem Artikel erfahren Sie, wie Sie eine verifizierte Verbindung zwischen dem Server und dem Client einrichten und diese verwenden. zum Senden von HTTP-Headern, die auf der Zulassungsliste stehen und nicht auf der Zulassungsliste stehen. Sie können hier springen: Add Extra Headers to Custom Tab Intents (Zusätzliche Header zu benutzerdefinierten Tab-Intents) für den Code hinzufügen.
Hintergrund
CORS-Anforderungsheader auf der Zulassungsliste und nicht auf der Zulassungsliste
Mit Cross-Origin Resource Sharing (CORS) kann eine Webanwendung von einem einzigen Ursprung aus Anfragen Ressourcen unterschiedlichen Ursprungs. Die Liste der CORS-Approve schalten-Header wird in der HTML Standard. In der nächsten Tabelle sehen Sie Beispiele für Titel, die auf der Zulassungsliste stehen:
| Header | Beschreibung |
|---|---|
| accept-language | bewirbt natürliche Sprachen, die der Kunde versteht |
| Inhaltssprache | beschreibt die für die aktuelle Zielgruppe vorgesehene Sprache. |
| Inhaltstyp | gibt den Medientyp der Ressource an |
Tabelle 2: Beispiele für CORS-Header auf Genehmigungsliste
Die genehmigten Titel gelten als sicher, da sie keine vertraulichen Informationen enthalten Nutzerinformationen und es ist unwahrscheinlich, dass der Server potenziell schädliche Vorgänge ausführt.
In der folgenden Tabelle finden Sie Beispiele für Header, die nicht auf der Genehmigungsliste stehen:
| Header | Beschreibung |
|---|---|
| bearer-token | authentifiziert Client auf einem Server |
| origin | gibt den Ursprung der Anfrage an |
| Keks | enthält vom Server festgelegte Cookies |
Tabelle 3: Beispiele für CORS-Header, die nicht auf der Zulassungsliste stehen
Das Anhängen von Headern, die nicht auf der Zulassungsliste stehen, an CORS-Anfragen wird vom HTML-Standard und von Servern abgeraten. gehen wir davon aus, dass ursprungsübergreifende Anfragen nur Header auf der Zulassungsliste enthalten. Header senden, die nicht auf der Genehmigungsliste stehen aus ursprungsübergreifenden Domains zu erlauben, dass schädliche Drittanbieter-Apps Header erstellen, die den Nutzer missbrauchen Cookies, die von Chrome oder einem anderen Browser gespeichert und an Anfragen angehängt werden Die Cookies könnten bösartige Transaktionen auf dem Server zu authentifizieren, die andernfalls nicht möglich wären.
CORS-Header auf der Zulassungsliste an Anfragen für benutzerdefinierte Tabs anhängen
Mit benutzerdefinierten Tabs lassen sich Webseiten in einem benutzerdefinierten Browsertab öffnen. Benutzerdefinierter Tab
Intents können mit CustomTabsIntent.Builder() erstellt werden. Sie können auch Header an diese
Intents mithilfe eines Bundle mit dem Flag Browser.EXTRA_HEADERS:
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"));
An CORS-Anfragen für benutzerdefinierte Tabs können wir immer Header mit Genehmigung anhängen. Die Chrome-Filter nicht auf der Zulassungsliste stehen. Andere Browser verhalten sich möglicherweise anders, -Entwickler sollten damit rechnen, dass Header, die nicht auf der Zulassungsliste stehen, generell blockiert werden.
Um Header, die nicht auf der Zulassungsliste stehen, in benutzerdefinierte Tabs aufzunehmen, müssen Sie zuerst überprüfen, über einen digitalen Zugriffslink. Im nächsten Abschnitt erfahren Sie, und starten Sie einen Intent für benutzerdefinierte Tabs mit den erforderlichen Headern.
Zusätzliche Header zu Intents für benutzerdefinierte Tabs hinzufügen
Digitale Asset-Links einrichten
Damit Header, die nicht auf der Zulassungsliste stehen, über Intents auf dem benutzerdefinierten Tab übergeben werden können, müssen Sie Folgendes festlegen: eine digitale Asset-Verknüpfung zwischen der Android- und der Webanwendung herzustellen, die bestätigt, dass der Autor besitzt beide Anwendungen.
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 bedeutet, dass beide Apps zum selben sobald der Link bestätigt wurde.
Benutzerdefinierten Tab-Intent mit zusätzlichen Headern erstellen
Es gibt mehrere Möglichkeiten, einen Intent für benutzerdefinierte Tabs zu erstellen. Sie können den verfügbaren Builder in androidX durch Hinzufügen der Bibliothek zu den Build-Abhängigkeiten:
MULTI_LINE_CODE_PLACEHOLDER_1
Erstellen Sie den Intent und fügen Sie zusätzliche Header hinzu:
MULTI_LINE_CODE_PLACEHOLDER_2
Richte eine Verbindung zu benutzerdefinierten Tabs ein, um den Asset-Link zu validieren
Eine Verbindung zu benutzerdefinierten Tabs wird verwendet, um ein CustomTabsSession zwischen der App und dem
Chrome-Tab. 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.
Es wird empfohlen, CustomTabsClient.warmup() anzurufen. Dadurch kann die Browseranwendung
im Hintergrund vorinitialisieren
und den URL-Aufruf beschleunigen.
MULTI_LINE_CODE_PLACEHOLDER_3
Richten Sie einen Callback ein, der den Intent nach der Validierung startet.
CustomTabsCallback wurde an die Sitzung übergeben. Wir richten die
onRelationshipValidationResult(), um die zuvor erstellte CustomTabsIntent zu starten
sobald die Ursprungsüberprüfung erfolgreich war.
MULTI_LINE_CODE_PLACEHOLDER_4
Dienstverbindung für benutzerdefinierte Tabs binden
Durch das Binden des Dienstes werden der Dienst und die onCustomTabsServiceConnected() der Verbindung gestartet
aufgerufen wird. Vergessen Sie nicht, die Bindung des Dienstes entsprechend aufzuheben. Bindungen und Aufheben der Bindung
erfolgt in der Regel in den Aktivitätslebenszyklusmethoden 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 Dienst für benutzerdefinierte Tabs Weitere Informationen finden Sie in der android-browser-helper-GitHub-Repository für eine funktionierende Beispiel-App.
Zusammenfassung
In diesem Leitfaden wurde veranschaulicht, wie Sie CORS-Anfragen für benutzerdefinierte Tabs beliebige Header hinzufügen können. Header auf Genehmigungsliste können an jede CORS-Anfrage für benutzerdefinierte Tabs angehängt werden. Header, die nicht auf der Zulassungsliste stehen, sind werden in CORS-Anfragen generell als unsicher eingestuft und sie werden von Chrome standardmäßig herausgefiltert. Die Verknüpfung Nur für Clients und Server desselben Ursprungs zulässig, bestätigt durch einen Digital Asset Link.