Les requêtes HTTP contiennent des en-têtes tels que User-Agent ou Content-Type. Hormis les en-têtes joints par
les navigateurs, les applications Android peuvent ajouter des en-têtes supplémentaires, comme "Cookie" ou "Referrer", via les
EXTRA_HEADERS Intention supplémentaire. Pour des raisons de sécurité, Chrome filtre certains des en-têtes supplémentaires
en fonction de l'endroit et du mode de lancement d'un intent.
Les requêtes d'origine croisée nécessitent une couche de sécurité supplémentaire, car le client et le serveur n'appartenant pas à la même partie. Ce guide explique comment lancer ce type de requêtes via Chrome Onglets personnalisés (intents lancés à partir d'applications qui ouvrent une URL dans l'onglet du navigateur) Jusqu'à Chrome 83, les développeurs pouvaient ajouter n'importe quel en-tête lors du lancement d'un onglet personnalisé. À partir de la version 83, Début du filtrage de tous les en-têtes multi-origines à l'exception de Looker listed, car les en-têtes non approuvés présentait un risque pour la sécurité. À partir de Chrome 86, il est possible de joindre des en-têtes non approuvés Les requêtes multi-origines, lorsque le serveur et le client sont liés par le biais d'un Digital Asset Link Ce comportement est résumé dans le tableau suivant:
| Version de Chrome | En-têtes CORS autorisés |
|---|---|
| avant Chrome 83 | sur liste d'approbation, sur liste d'approbation, non sur liste |
| De Chrome 83 à Chrome 85 | sur liste d'approbation |
| à partir de Chrome 86 ; | sur liste d'approbation, sur liste non approuvée lorsqu'un lien vers des ressources numériques est configuré |
Tableau 1 : Filtrage des en-têtes CORS non approuvés
Cet article explique comment configurer une connexion vérifiée entre le serveur et le client et comment utiliser cette pour envoyer des en-têtes HTTP ajoutés à la liste d'approbation et non approuvés. Vous pouvez passer à Ajout d'en-têtes supplémentaires aux intents d'onglet personnalisés pour le code
Contexte
En-têtes des demandes CORS ajoutées à la liste d'approbation et non approuvées
Le partage des ressources entre origines multiples (CORS, Cross-Origin Resource Sharing) permet à une application Web d'envoyer des requêtes aux ressources d'origine différente. La liste des en-têtes approuvés par CORS est conservée dans la Norme HTML : Des exemples d'en-têtes sur liste d'approbation sont présentés dans le tableau suivant:
| Header | Description |
|---|---|
| accept-language | fait la promotion des langages naturels que le client comprend |
| langue du contenu | décrit le langage destiné à l'audience actuelle |
| type-contenu | indique le type de support de la ressource |
Tableau 2 : Exemples d'en-têtes CORS ajoutés à la liste d'approbation
Les en-têtes de la liste d'approbation sont considérés comme sûrs, car ils ne contiennent pas de données sensibles informations utilisateur et il est peu probable que le serveur effectue des opérations potentiellement préjudiciables.
Vous trouverez des exemples d'en-têtes non approuvés dans le tableau suivant:
| Header | Description |
|---|---|
| bearer-token | authentifie le client auprès d'un serveur |
| origine | indique l'origine de la requête |
| biscuit | contient des cookies définis par le serveur |
Tableau 3 : Exemples d'en-têtes CORS non approuvés.
La norme HTML et les serveurs déconseillent de joindre des en-têtes non approuvés (approuvés) aux demandes CORS partent du principe que les demandes multi-origines ne contiennent que des en-têtes sur liste d'approbation. Envoyer des en-têtes non approuvés de domaines multi-origines permettrait à des applications tierces malveillantes de créer des en-têtes qui font un usage abusif des utilisateurs. les cookies stockés et joints aux requêtes par Chrome (ou un autre navigateur). Les cookies pourraient authentifier des transactions serveur malveillantes qui ne seraient pas possibles autrement.
Joindre des en-têtes de la liste d'approbation CORS aux requêtes d'onglets personnalisés
Les onglets personnalisés permettent d'ouvrir des pages Web dans un onglet personnalisé du navigateur. Onglet personnalisé
les intents peuvent être créés à l'aide de CustomTabsIntent.Builder(). Vous pouvez également joindre
des en-têtes à ces
intents à l'aide d'un Bundle avec l'option 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"));
Nous pouvons toujours joindre des en-têtes de la liste d'approbation aux onglets personnalisés aux requêtes CORS. Toutefois, Chrome filtre les en-têtes non approuvés par défaut. Bien que le comportement des autres navigateurs puisse être différent, les développeurs doivent s'attendre à ce que les en-têtes non répertoriés dans la liste d'approbation soient bloqués en général.
Pour inclure des en-têtes non approuvés dans les onglets personnalisés, vous devez d'abord vérifier multi-origines via une liaison d'accès numérique. La section suivante explique comment définir et lancer un intent d'onglets personnalisés avec les en-têtes requis.
Ajouter des en-têtes supplémentaires aux intents d'onglet personnalisés
Configurer Digital Asset Links
Pour permettre le transfert des en-têtes non approuvés via les intents de l'onglet personnalisé, vous devez définir un lien de contenu numérique entre l'application Android et l'application Web qui vérifie que l'auteur possède les deux applications.
Suivez le guide officiel pour configurer un lien vers des ressources numériques. Pour la relation de relation, utilisez "delegate_permission/common.use_as_origin" indique que les deux applications appartiennent au même une fois l'association validée.
Créer un intent d'onglet personnalisé avec des en-têtes supplémentaires
Il existe plusieurs façons de créer un intent d'onglets personnalisés. Vous pouvez utiliser l'outil de création disponible dans androidX en ajoutant la bibliothèque aux dépendances de compilation:
MULTI_LINE_CODE_PLACEHOLDER_1
Créez l'intent et ajoutez des en-têtes supplémentaires:
MULTI_LINE_CODE_PLACEHOLDER_2
Configurer une connexion à des onglets personnalisés pour valider le lien de l'élément
Une connexion aux onglets personnalisés permet de configurer un CustomTabsSession entre l'application et la
Onglet Chrome. Nous avons besoin de la session pour vérifier que l'application et l'application Web appartiennent à la même origine.
La validation n'est validée que si les liens vers des ressources numériques ont été correctement configurés.
Nous vous recommandons d'appeler CustomTabsClient.warmup(). Il permet à l'application de navigateur
pré-initialisent en arrière-plan et accélèrent le processus d'ouverture de l'URL.
MULTI_LINE_CODE_PLACEHOLDER_3
Configurer un rappel qui lance l'intent après la validation
Le CustomTabsCallback a été transmis dans la session. Nous configurons
onRelationshipValidationResult() pour lancer le CustomTabsIntent créé précédemment
une fois la vérification de l'origine effectuée.
MULTI_LINE_CODE_PLACEHOLDER_4
Lier la connexion du service des onglets personnalisés
La liaison du service lance le service et le onCustomTabsServiceConnected() de la connexion
sera appelé à terme. N'oubliez pas de dissocier le service de manière appropriée. Liaison et dissociation
s'effectue généralement dans les méthodes du cycle de vie de l'activité onStart() et 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 de l'application de démonstration
Pour en savoir plus sur le service d'onglets personnalisés, cliquez ici. Consultez le android-browser-helper pour un exemple d'application fonctionnel.
Résumé
Ce guide explique comment ajouter des en-têtes arbitraires aux onglets personnalisés dans les requêtes CORS. Les en-têtes de la liste d'approbation peuvent être joints à chaque requête CORS d'onglets personnalisés. Les en-têtes non approuvés sont généralement considérés comme non sécurisés dans les requêtes CORS. Chrome les filtre par défaut. Les joindre est autorisé uniquement pour les clients et les serveurs de même origine, validés par un lien vers des ressources numériques.