Anweisungsliste erstellen

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.