Erstellen einer Anweisungsliste

Erklärungen werden in einer JSON-codierten Erklärungsliste an einem bekannten Ort auf einem Prinzipal gehostet, wie in der Asset Links-Spezifikation definiert. Eine Anweisungsliste enthält eine oder mehrere Anweisungen und ein Rechtssubjekt kann nur eine Anweisungsliste haben.

Syntax der Anweisungsliste

Syntax für Anweisungslisten

Speicherort der Abrechnungsliste

Die Erklärungsliste wird an einem bekannten Ort gehostet, der vom Typ des Rechtssubjekts (der Website oder App, die die Erklärungen abgibt) abhängt.

Listen mit Websiteerklärungen

Auf einer Website ist eine Anweisungsliste eine Textdatei, die sich unter der folgenden Adresse befindet:

scheme://domain/.well-known/assetlinks.json

Beachten Sie den Punkt im Ordnernamen „.well-known“.

Jede Antwort vom Server, die nicht HTTP 200 ist, wird als Fehler behandelt und führt zu einer leeren Anweisungsliste. Bei HTTPS führt jede Verbindung ohne Zertifikatskette, die mit der Liste der vertrauenswürdigen Stammzertifikate überprüft werden kann, ebenfalls zu einer leeren Anweisungsliste.

Beispiel

Hier ist ein Beispiel für eine Anweisungsliste auf einer Website: http://example.digitalassetlinks.org/.well-known/assetlinks.json

Listen mit Erklärungen zu Android-Apps

In einer Android-App ist die Erklärungsliste ein JSON-Snippet mit derselben Syntax wie eine Website-Erklärungsdatei. Sie ist jedoch in die Datei „strings.xml“ eingebettet und wird wie unten gezeigt im Manifest referenziert.

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 einen Ausschnitt aus res/values/strings.xml für eine Android-App, die die Standortfreigabe mit der 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>

Zielvorhaben abgleichen

Jede Aussage bezieht sich auf ein Ziel. Wenn Sie eine Aussage lesen, müssen Sie das Ziel in der Aussage mit einer realen Einheit abgleichen. Wenn das Ziel der Aussage mit der Entität übereinstimmt, wird die Aussage angewendet. Hier sind die Regeln, anhand derer bestimmt wird, ob ein Ziel mit einer bestimmten Entität übereinstimmt:

Website-Ziele

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 Anweisungstarget http://www.beispiel.de:80 beschreibt, gilt die Website http://www.beispiel.de als Übereinstimmung.

Beispiel

Angenommen, das Ziel der Aussage ist

"target": {
  "namespace": "web",
  "site": "https://www.google.com"
}

Die folgenden URIs STIMMEN mit dem Präfix überein:

  • 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 mit dem Präfix ü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 Zertifikathash und der Paketname des Ziels genau mit der Anwendung übereinstimmen.