Les instructions sont hébergées dans une liste d'instructions encodées au format JSON, à un emplacement connu sur 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 seule.
Syntaxe de la liste d'instructions
Consultez la syntaxe de la liste d'instructions.
Emplacement de la liste des relevés
La liste des relevés est hébergée à un emplacement connu qui dépend du type de principal (site Web ou application à l'origine des déclarations).
Listes des relevés de sites 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 autre que HTTP 200 est traitée comme une erreur et entraîne l'affichage d'une liste d'instructions vide. Pour HTTPS, toute connexion sans chaîne de certificats pouvant être validée avec la liste racine de confiance entraînera également une liste d'instructions vide.
Exemple
Voici un exemple de liste de relevés sur un site Web: http://example.digitalassetlinks.org/.well-known/assetlinks.json
Listes de relevés d'application Android
Dans une application Android, la liste des instructions est un extrait de code JSON ayant la même syntaxe qu'un fichier d'instruction de site Web, mais elle est intégrée au fichier string.xml et référencée dans le fichier manifeste, comme indiqué ci-dessous.
Dans le fichier 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 compatible avec le partage de position avec cette application (fonctionnalité Android non compatible actuellement):
<resources>
...
<string name="asset_statements">
[{
\"relation\": [\"delegate_permission/common.share_location\"],
\"target\": {
\"namespace\": \"web\",
\"site\": \"https://example.com\"
}
}]
</string>
</resources>
Correspondance avec une cible
Chaque instruction concerne une cible. Lorsque vous consommez une instruction, vous devez faire correspondre la cible dans une instruction avec une entité en réalité. Si la cible de l'instruction correspond à l'entité, l'instruction s'applique. Voici les règles permettant de déterminer si une cible correspond à une entité donnée:
Cibles de sites Web
Pour un site Web, le schéma du site, l'hôte et le port doivent correspondre exactement. Les ports par défaut pour HTTP et HTTPS (80 et 443, respectivement) sont supposés être utilisés. 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 de déclaration suivante :
"target": {
"namespace": "web",
"site": "https://www.google.com"
}
Les URI suivants APPROUVERONT:
- 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://utilisateur@motdepasse:www.google.com/
Les URL suivantes NE correspondent PAS:
- http://www.google.com/ (schéma incorrect)
- https://google.com/ (Host name does not match)
- https://www.google.com:444/ (Le port ne correspond pas)
Cibles d'application
Pour une application, le hachage de certificat et le nom de package de la cible doivent correspondre exactement à l'application.