Les déclarations sont hébergées dans une liste de déclarations encodées au format JSON à un emplacement bien connu d'un principal, tel que défini par la spécification Asset Links. Une liste d'instructions contient une ou plusieurs instructions, et un principal ne peut avoir qu'une seule liste d'instructions.
Syntaxe de la liste d'instructions
Consultez la syntaxe de la liste des instructions.
Emplacement de la liste des relevés
La liste des déclarations est hébergée dans un emplacement bien connu qui dépend du type de principal (le site Web ou l'application qui fait les déclarations).
Listes des déclarations sur le site Web
Sur un site Web, une liste d'énoncé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 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 entraînera également une liste d'instructions vide.
Exemple
Voici un exemple de liste d'énoncés sur un site Web : http://example.digitalassetlinks.org/.well-known/assetlinks.json
Listes d'énoncés d'applications Android
Dans une application Android, la liste des déclarations est un extrait JSON dont la syntaxe est identique à celle d'un fichier de déclaration de site Web. Toutefois, elle est intégrée au fichier strings.xml et référencée dans le fichier manifeste, comme indiqué 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 compatible avec le partage de position avec l'application (une 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>Mettre en correspondance une cible
Chaque instruction concerne une cible. Lorsque vous consommez une déclaration, vous devez faire correspondre la cible d'une déclaration à une entité réelle. Si la cible de la déclaration correspond à l'entité, la déclaration s'applique. Voici les règles permettant de déterminer si une cible correspond à une entité donnée :
Cibles de site Web
Pour un site Web, le schéma, l'hôte et le port du site doivent correspondre exactement. Les ports par défaut pour HTTP et HTTPS (80 et 443, respectivement) sont supposés implicitement. 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 l'instruction 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'application
Pour une application, le hachage du certificat et le nom du package de la cible doivent correspondre exactement à ceux de l'application.