Tworzenie listy wyciągów

Wyciągi są przechowywane na liście wyciągów w formacie JSON w dobrze znanej lokalizacji podmiotu zabezpieczeń, zgodnie z definicją w specyfikacji linków zasobów. Lista wyciągów zawiera co najmniej 1 wyciąg, a podmiot zabezpieczeń może mieć tylko 1 listę.

Składnia listy wyciągu

Sprawdź składnię listy wyrażeń.

Lokalizacja na wyciągu

Lista wyrażeń znajduje się w dobrze znanej lokalizacji, która zależy od typu podmiotu zabezpieczeń (witryny lub aplikacji tworzącej wyciągi).

Listy z wyciągami z witryny

W witrynie lista z wyciągami to plik tekstowy pod tym adresem:

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

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

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

Przykład

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

Lista wyciągów z aplikacji na Androida

W aplikacji na Androida lista instrukcji jest fragmentem kodu JSON o tej samej składni co plik instrukcji witryny, ale jest umieszczony w pliku string.xml i odwołania do niego 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>

Plik res/values/strings.xml:

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

Przykład

Oto przykładowy fragment kodu res/values/strings.xml dotyczący aplikacji na Androida, która obsługuje udostępnianie lokalizacji w aplikacji (funkcja Androida 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>

Dopasowanie do celu

Każde stwierdzenie dotyczy celu. Analizując dane, musisz dopasować wartości docelowe do tych w rzeczywistości. Jeśli wartość docelowa wyrażenia jest zgodna z encją, zostanie ona zastosowana. Oto reguły, które pozwalają określić, czy cel pasuje do danego elementu:

Cele dotyczące witryn

W przypadku witryny schemat witryny, host i port muszą być dokładnie takie same. Domyślne porty HTTP i HTTPS (odpowiednio 80 i 443) są domyślnie traktowane jako domyślne. Jeśli instrukcja docelowa zawiera opis http://www.example.com:80, witryna http://www.example.com jest uznawana za pasującą.

Przykład

Podany cel instrukcji

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

Te identyfikatory URI SĄ zgodne:

  • 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://użytkownik@hasło:www.google.com/

Te adresy URL NIE będą pasować:

  • http://www.google.com/ (niewłaściwy schemat)
  • https://google.com/ (nazwa hosta nie pasuje)
  • https://www.google.com:444/ (Port nie pasuje)

Cele aplikacji

W przypadku aplikacji hasz certyfikatu i nazwa pakietu docelowego muszą być zgodne z nazwą aplikacji.