Anweisungen werden in einer JSON-codierten Anweisungsliste an einem bekannten Speicherort in einem Hauptkonto gehostet, wie in der Spezifikation für Asset-Links definiert. Eine Anweisungsliste enthält eine oder mehrere Anweisungen und ein Hauptkonto kann nur eine Anweisungsliste haben.
Syntax der Anweisungsliste
Siehe Syntax der Anweisungsliste.
Speicherort der Anweisungsliste
Die Liste der Anweisungen befindet sich an einem bekannten Ort, der vom Typ des Hauptkontos abhängig ist (Website oder App, von der die Anweisungen stammen).
Listen mit Website-Kontoauszug
Auf einer Website ist eine Anweisungsliste eine Textdatei, die sich unter der folgenden Adresse befindet:
scheme://domain/.well-known/assetlinks.json
Achten Sie auf den Punkt im Ordnernamen „.well-known“.
Jede Antwort vom Server mit Ausnahme von HTTP 200 wird als Fehler behandelt und führt zu einer leeren Anweisungsliste. Bei HTTPS führt jede Verbindung ohne Zertifikatskette, die mit der vertrauenswürdigen Stammliste verifiziert werden kann, zu einer leeren Anweisungsliste.
Beispiel
Hier ist ein Beispiel für eine Erklärung auf einer Website: http://example.digitalassetlinks.org/.well-known/assetlinks.json
Statement-Listen für Android-Apps
In einer Android-App ist die Anweisungsliste ein JSON-Snippet mit derselben Syntax wie eine Website-Anweisungsdatei. Sie ist jedoch in die Datei "strings.xml" eingebettet und im Manifest referenziert, wie unten dargestellt.
In AndroidManifest.xml:
<manifest>
<application>
...
<meta-data android:name="asset_statements" android:resource="@string/asset_statements" />
...
</application>
</manifest>
In res/values/strings.xml:
<resources>
...
<string name="asset_statements">
... statement list ...
</string>
</resources>
Beispiel
Hier ist ein Beispiel für ein res/values/strings.xml-Snippet für eine Android-App, die die Standortfreigabe über die App unterstützt (eine Android-Funktion, die derzeit nicht unterstützt wird):
<resources>
...
<string name="asset_statements">
[{
\"relation\": [\"delegate_permission/common.share_location\"],
\"target\": {
\"namespace\": \"web\",
\"site\": \"https://example.com\"
}
}]
</string>
</resources>
Übereinstimmung mit einem Ziel
Jede Aussage bezieht sich auf ein Ziel. Wenn Sie eine Anweisung verarbeiten, müssen Sie das Ziel in einer Anweisung in Wirklichkeit mit einer Entität abgleichen. Wenn das Anweisungsziel mit der Entität übereinstimmt, wird die Anweisung angewendet. Anhand der folgenden Regeln lässt sich feststellen, ob ein Ziel mit einer bestimmten Entität übereinstimmt:
Websiteziele
Bei einer Website müssen Site-Schema, Host und Port genau übereinstimmen. Standardports für HTTP und HTTPS (80 bzw. 443) werden implizit angenommen. Wenn ein Anweisungsziel http://www.example.com:80 beschreibt, wird die Website http://www.example.com als Übereinstimmung angesehen.
Beispiel
Bei der folgenden Zielanweisung
"target": {
"namespace": "web",
"site": "https://www.google.com"
}
Die folgenden URIs WERDEN übereinstimmen:
- 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/
Die folgenden URLs stimmen NICHT überein:
- http://www.google.com/ (Falsches Schema)
- https://google.com/ (Hostname stimmt nicht überein)
- https://www.google.com:444/ (Port stimmt nicht überein)
App-Ziele
Bei einer App müssen der Zertifikats-Hash und der Paketname des Ziels genau mit der App übereinstimmen.