Les instructions sont hébergées dans une liste d'instructions encodée au format JSON dans un emplacement bien connu d'un compte principal, tel que défini par la spécification des liens d'éléments. Une liste d'instructions contient une ou plusieurs instructions, et un compte principal ne peut en avoir qu'une.
Syntaxe de la liste d'instructions
Reportez-vous à la syntaxe de la liste d'instructions.
Emplacement de la liste de relevés
La liste d'instructions est hébergée à un emplacement bien connu qui dépend du type de compte principal (site Web ou application à l'origine des déclarations).
Listes d'instructions pour le site Web
Sur un site Web, une liste de relevés est un fichier texte situé à l'adresse suivante:
scheme://domain/.well-known/assetlinks.json
Notez le point dans le nom du dossier .well-known.
Toute réponse du serveur à l'exception de HTTP 200 est traitée comme une erreur et génère une liste d'instructions vide. Pour HTTPS, toute connexion sans chaîne de certificats pouvant être vérifiée avec la liste racine de confiance génère également une liste d'instructions vide.
Exemple
Voici un exemple de liste d'instructions sur un site Web: http://example.digitalassetlinks.org/.well-known/assetlinks.json
Listes des instructions d'application Android
Dans une application Android, la liste d'instructions est un extrait de code JSON ayant la même syntaxe qu'un fichier d'instructions de site Web, mais elle est intégrée au fichier string.xml et référencée dans le fichier manifeste, comme illustré ci-dessous.
Dans AndroidManifest.xml :
<manifest>
<application>
...
<meta-data android:name="asset_statements" android:resource="@string/asset_statements" />
...
</application>
</manifest>
Dans res/values/strings.xml:
<resources>
...
<string name="asset_statements">
... statement list ...
</string>
</resources>
Exemple
Voici un exemple d'extrait res/values/strings.xml pour une application Android qui prend en charge le partage de position avec l'application (fonctionnalité Android actuellement non disponible):
<resources>
...
<string name="asset_statements">
[{
\"relation\": [\"delegate_permission/common.share_location\"],
\"target\": {
\"namespace\": \"web\",
\"site\": \"https://example.com\"
}
}]
</string>
</resources>
Mise en correspondance d'une cible
Chaque instruction concerne une cible. Lorsque vous utilisez une instruction, vous devez faire correspondre la cible d'une instruction avec une entité réelle. Si la cible de l'instruction correspond à l'entité, l'instruction s'applique. Voici les règles qui vous permettent de déterminer si une cible correspond à une entité donnée:
Cibles de sites Web
Dans le cas d'un site Web, le schéma, l'hôte et le port doivent correspondre exactement. Les ports par défaut pour HTTP et HTTPS (respectivement 80 et 443) sont implicites. Si une cible d'instruction décrit http://www.example.com:80, le site Web http://www.example.com est considéré comme une correspondance.
Exemple
Compte tenu de la cible suivante :
"target": {
"namespace": "web",
"site": "https://www.google.com"
}
Les URI suivants correspondent :
- https://www.google.com/
- https://www.google.com:443/
- https://www.google.com/foo
- https://www.google.com/foo?bar
- https://www.google.com/foo#bar
- https://user@password:www.google.com/
Les URL suivantes ne correspondent PAS:
- http://www.google.com/ (schéma incorrect)
- https://google.com/ (Le nom d'hôte ne correspond pas)
- https://www.google.com:444/ (Le port ne correspond pas)
Cibles d'applications
Pour une application, le hachage du certificat et le nom de package de la cible doivent correspondre exactement à l'application.