Anweisungen werden in einer JSON-codierten Anweisungsliste an einem bekannten Speicherort auf einem Hauptkonto gehostet, wie in der Asset-Link-Spezifikation definiert. Eine Anweisungsliste enthält eine oder mehrere Anweisungen und ein Hauptkonto kann nur eine Anweisungsliste haben.
Syntax der Anweisungsliste
Siehe Syntax der Anweisungsliste.
Position der Anweisungsliste
Die Anweisungsliste wird an einem bekannten Ort gehostet, der vom Typ des Hauptkontos abhängt (Website oder App, von der die Aussagen stammen).
Listen mit Website-Anweisungen
Auf einer Website ist eine Anweisungsliste eine Textdatei unter der folgenden Adresse:
scheme://domain/.well-known/assetlinks.json
Beachten Sie den Punkt im .well-known-Ordnernamen.
Jede Antwort vom Server außer 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 findest du eine Beispielliste für Anweisungen auf einer Website: http://example.digitalassetlinks.org/.well-known/assetlinks.json
Listen mit Kontoauszügen 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 wird im Manifest wie unten gezeigt referenziert.
In der Datei 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 ein Beispiel für res/values/strings.xml-Snippets einer Android-App, die die Standortfreigabe für 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 Anweisung bezieht sich auf ein Ziel. Wenn Sie eine Anweisung nutzen, müssen Sie das Ziel in einer Anweisung mit einer Entität in der Realität abgleichen. Wenn das Anweisungsziel mit der Entität übereinstimmt, gilt die Anweisung. Die folgenden Regeln bestimmen, ob ein Ziel mit einer bestimmten Entität übereinstimmt:
Websiteziele
Bei einer Website müssen das Schema, der Host und der Port der Website exakt ü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
Mit dem folgenden Anweisungsziel
"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://nutzer@passwort:www.google.de/
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 Anwendung müssen der Zertifikats-Hash und der Paketname des Ziels genau mit der Anwendung übereinstimmen.