Instrukcje są przechowywane na liście instrukcji zakodowanej w formacie JSON w dobrze znanej lokalizacji podmiotu zabezpieczeń zgodnie z definicją podaną w specyfikacji linków zasobów. Lista instrukcji zawiera co najmniej 1 instrukcję, a podmiot zabezpieczeń może mieć tylko jedną listę.
Składnia listy instrukcji
Zobacz składnię listy instrukcji.
Lokalizacja listy instrukcji
Lista wyciągów znajduje się w dobrze znanym miejscu, w zależności od typu podmiotu (witryna lub aplikacja składająca oświadczenie).
Listy z wyciągami z witryn
W witrynie lista wyciągów 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 oprócz HTTP 200 jest traktowana jako błąd i spowoduje pustą listę instrukcji. W przypadku protokołu HTTPS każde połączenie bez łańcucha certyfikatów, które można zweryfikować na liście zaufanych certyfikatów, również spowoduje wyświetlenie pustej listy instrukcji.
Przykład
Oto przykładowa lista instrukcji na stronie internetowej: http://example.digitalassetlinks.org/.well-known/assetlinks.json
Listy z wyciągami dotyczącymi aplikacji na Androida
W przypadku aplikacji na Androida lista instrukcji to fragment kodu JSON o takiej samej składni jak plik z instrukcjami dotyczącymi witryny, ale umieszczony w pliku hosts.xml i odnosi się 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 na Androida, który obsługuje udostępnianie lokalizacji aplikacji (funkcja na 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 wartości docelowej
Każde stwierdzenie dotyczy celu. Analizując sformułowanie, musisz dopasować jego cel do jakiegoś podmiotu w rzeczywistości. Jeśli cel wyrażenia pasuje do jednostki, zostanie zastosowana instrukcja. Oto reguły, które pozwalają ustalić, czy cel pasuje do danego elementu:
Cele w witrynie
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ą przyjmowane domyślnie. Jeśli cel instrukcji zawiera adres http://www.example.com:80, witryna http://www.example.com jest uznawana za pasującą.
Przykład
Przy uwzględnieniu następującego celu oświadczenia
"target": { "namespace": "web", "site": "https://www.google.com" } Te identyfikatory URI BĘDĄ 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://user@password:www.google.com/
Te adresy URL NIE będą pasować:
- http://www.google.com/ (Nieprawidłowy schemat)
- https://google.com/ (niezgodna nazwa hosta)
- https://www.google.com:444/ (niezgodny port)
Cele aplikacji
W przypadku aplikacji hasz certyfikatu i nazwa pakietu środowiska docelowego muszą dokładnie odpowiadać aplikacji.