Tworzenie listy instrukcji

Oświadczenia są hostowane na liście oświadczeń zakodowanej w formacie JSON w dobrze znanym miejscu na podmiocie, zgodnie ze specyfikacją linków do zasobów. Lista oświadczeń zawiera co najmniej jedno oświadczenie, a podmiot może mieć tylko jedną listę oświadczeń.

Składnia listy instrukcji

Zobacz składnię listy instrukcji.

Lokalizacja listy wyciągów

Lista oświadczeń jest hostowana w dobrze znanej lokalizacji, która zależy od typu podmiotu (witryny lub aplikacji składającej oświadczenia).

Listy oświadczeń w witrynie

W witrynie lista oświadczeń to plik tekstowy znajdujący się pod tym adresem:

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

Zwróć uwagę na kropkę w nazwie folderu .well-known.

Każda odpowiedź z serwera inna niż HTTP 200 jest traktowana jako błąd i skutkuje pustą listą instrukcji. W przypadku protokołu HTTPS każde połączenie bez łańcucha certyfikatów, którego nie można zweryfikować za pomocą listy zaufanych certyfikatów głównych, również spowoduje wyświetlenie pustej listy instrukcji.

Przykład

Oto przykładowa lista instrukcji w witrynie: http://example.digitalassetlinks.org/.well-known/assetlinks.json

Listy oświadczeń dotyczące aplikacji na Androida

W aplikacji na Androida lista instrukcji to fragment kodu JSON o takiej samej składni jak plik instrukcji witryny, ale jest on osadzony w pliku strings.xml i odwoływany w pliku manifestu, jak pokazano poniżej.

W pliku AndroidManifest.xml:

<manifest>
  <application>
    ...
    <meta-data android:name="asset_statements" android:resource="@string/asset_statements" />
    ...
  </application>
</manifest>

W pliku res/values/strings.xml:

<resources>
  ...
  <string name="asset_statements">
    ... statement list ...
  </string>
</resources>

Przykład

Oto przykładowy fragment pliku res/values/strings.xml w aplikacji na Androida, która obsługuje udostępnianie lokalizacji w aplikacji (funkcja Androida, która nie jest obecnie obsługiwana):

<resources>
    ...
    <string name="asset_statements">
      [{
        \"relation\": [\"delegate_permission/common.share_location\"],
        \"target\": {
          \"namespace\": \"web\",
          \"site\": \"https://example.com\"
        }
      }]
    </string>
</resources>

Dopasowywanie do elementu docelowego

Każde stwierdzenie dotyczy celu. Gdy analizujesz stwierdzenie, musisz dopasować cel w stwierdzeniu do jakiegoś obiektu w rzeczywistości. Jeśli cel instrukcji pasuje do elementu, instrukcja jest stosowana. Oto reguły określające, czy cel pasuje do danej encji:

Miejsca docelowe w witrynach

W przypadku witryny schemat, host i port muszą być dokładnie takie same. Domyślne porty dla protokołów HTTP i HTTPS (odpowiednio 80 i 443) są przyjmowane domyślnie. Jeśli element docelowy instrukcji opisuje adres http://www.example.com:80, to witryna http://www.example.com jest uznawana za pasującą.

Przykład

Biorąc pod uwagę to kierowanie na stwierdzenie:

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

Te identyfikatory URI BĘDĄ pasować:

  • 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/

Te adresy URL NIE BĘDĄ pasować:

  • http://www.google.com/ (Nieprawidłowy schemat)
  • https://google.com/ (Nazwa hosta nie pasuje)
  • https://www.google.com:444/ (Port does not match)

Aplikacje docelowe

W przypadku aplikacji skrót certyfikatu i nazwa pakietu muszą dokładnie odpowiadać aplikacji.