Pierwsze kroki
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Przegląd
Protokół i interfejs API Digital Asset Links umożliwiają aplikacji lub witrynie publikowanie publicznych, możliwych do zweryfikowania oświadczeń o innych aplikacjach lub witrynach. Witryna może na przykład zadeklarować, że jest powiązana z konkretną aplikacją na Androida, lub że chce udostępniać dane użytkownika innej witrynie.
Oto kilka możliwych zastosowań funkcji Digital Asset Links:
- Strona A deklaruje, że linki do niej powinny otwierać się w wyznaczonej aplikacji na urządzeniach mobilnych, jeśli jest ona zainstalowana.
- Witryna A deklaruje, że może udostępniać swoje dane logowania użytkownika Chrome witrynie B, dzięki czemu nie będzie musiał logować się w witrynie B, jeśli jest zalogowany w witrynie A.
- Aplikacja A deklaruje, że może udostępniać stronie B ustawienia urządzenia, takie jak lokalizacja.
Kluczowe terminy
- Podmiot zabezpieczeń: podmiotem zabezpieczeń jest aplikacja lub witryna, która złożyła oświadczenie. W linkach do zasobów cyfrowych podmiotem zabezpieczeń jest zawsze aplikacja lub witryna hostująca listę instrukcji.
- Lista wyciągów: instrukcje znajdują się na liście instrukcji, która zawiera co najmniej 1 instrukcję. Lista instrukcji jest tekstem jawnym i publicznie dostępna, znajdującą się w lokalizacji kontrolowanej przez podmiot zabezpieczeń i trudnych do podrobienia lub modyfikacji.
Może to być wolnostojący plik lub sekcja innego, większego elementu. Na przykład w witrynie jest to cały plik, a w aplikacji na Androida – sekcja w manifeście aplikacji.
Wyciągi mogą wyświetlać i weryfikować każdy, korzystając z niezastrzeżonych metod. Więcej informacji znajdziesz w dokumentacji listy wyciągów
- Oświadczenie: instrukcja to ściśle uporządkowany konstrukcja JSON, który składa się z relation (zgodnie z definicją, np. „Włącz udostępnianie danych uwierzytelniających”) i relation (witryny lub aplikacji, do której odnosi się dany związek). Dlatego każde stwierdzenie jest jak zdanie, w którym podmiot zabezpieczeń mówi relacja o celu.
- Konsument oświadczenia: klient korzystający z wyciągu prosi o listę wyciągów od podmiotu zabezpieczeń, sprawdza, czy istnieje oświadczenie dotyczące danego podmiotu zabezpieczeń i jeśli istnieje, może wykonać określone działanie. Więcej informacji znajdziesz w oświadczeniu dołączonym do dokumentacji.
Przykład szybkiego użycia
Oto bardzo uproszczony przykład wykorzystania w witrynie www.example.com linku do zasobów cyfrowych, który pozwala określić, że wszystkie linki do adresów URL w tej witrynie powinny otwierać się w wyznaczonej aplikacji, a nie w przeglądarce:
- Witryna www.example.com publikuje listę instrukcji pod adresem https://www.example.com/.well-known/assetlinks.json. To jest oficjalna nazwa i lokalizacja listy oświadczeń w witrynie. Listy z wyciągami z jakiejkolwiek innej lokalizacji nie mają zastosowania w tej witrynie. W naszym przykładzie lista instrukcji składa się z 1 instrukcji przyznającej aplikacji na Androida uprawnienia do otwierania linków w witrynie:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target" : { "namespace": "android_app", "package_name": "com.example.app",
"sha256_cert_fingerprints": ["hash_of_app_certificate"] }
}]Lista instrukcji obsługuje tablicę instrukcji w znakach [ ], ale nasz przykładowy plik zawiera tylko jedną instrukcję.
sha256_cert_fingerprints to odciski cyfrowe SHA256 certyfikatu podpisywania Twojej aplikacji.
Więcej informacji znajdziesz w dokumentacji dotyczącej linków aplikacji na Androida.
- Aplikacja na Androida wymieniona w powyższej instrukcji ma filtr intencji, który określa schemat, hosta i wzorzec ścieżki adresów URL, które chce obsługiwać: w tym przypadku https://www.example.com. Filtr intencji zawiera specjalny atrybut
android:autoVerify (nowy w Androidzie M), który wskazuje, że po zainstalowaniu aplikacji Android powinien zweryfikować instrukcję na stronie opisanej w filtrze intencji.
- Użytkownik instaluje aplikację. Android wykrywa filtr intencji z atrybutem
autoVerify i sprawdza, czy w danej witrynie znajduje się lista instrukcji. Jeśli taka lista jest dostępna, Android sprawdza, czy plik zawiera oświadczenie przyznające obsługę linku do aplikacji i weryfikuje aplikację pod kątem tego wyrażenia za pomocą haszowania certyfikatu. Jeśli wszystko będzie w porządku, Android przekaże do aplikacji example.com wszystkie intencje https://www.example.com.
- Użytkownik klika na swoim urządzeniu link do strony https://www.example.com/szczeniaki. Ten link może znajdować się w dowolnym miejscu: w przeglądarce,
sugestii Google Search Appliance lub dowolnym innym miejscu. Android przekazuje intencję do aplikacji example.com.
- Aplikacja example.com otrzymuje intencję i postanawia ją obsłużyć i otwiera w aplikacji stronę o szczeniakach. Jeśli z jakiegoś powodu aplikacja odmówiła obsługi linku lub jeśli aplikacji nie ma na urządzeniu, link zostałby wysłany do następnego domyślnego modułu obsługi intencji pasującej do tego wzorca intencji (często do przeglądarki).
Ważne informacje i ograniczenia:
- Protokół nie uwierzytelnia podmiotu zabezpieczeń składającego instrukcję, ale instrukcja znajduje się w konkretnej lokalizacji silnie powiązanej z podmiotem zabezpieczeń i pod jego kontrolą.
- Protokół nie uwierzytelnia celu instrukcji, ale zapewnia urządzeniu wywołującemu metodę uwierzytelniania środowiska docelowego (np. instrukcja identyfikuje cele aplikacji mobilnych według hasza certyfikatu i nazwy pakietu).
- Protokół nie wykonuje natywnie żadnych działań związanych z instrukcjami; umożliwia ujawnianie instrukcji, których weryfikacja musi zostać sprawdzona przez aplikację używaną w celu, a następnie decydować o tym, czy i jak podjąć dalsze działania. Android M natywnie wykonuje te czynności za Ciebie. Jeśli np. witryna przekazuje obsługę linków do określonej aplikacji, Android sprawdza i weryfikuje instrukcję, weryfikuje aplikację docelową, a następnie oferuje aplikacji możliwość obsługi danego linku.
- Protokół nie umożliwia wygłaszania oświadczeń dotyczących 2 osób trzecich: oznacza to, że witryna A może złożyć oświadczenie dotyczące witryny B, ale witryna A nie może udzielać informacji na temat relacji między witryną B a witryną C. Jeśli jednak witryna B ufa witrynie A, może ona sprawdzić, czy znajduje się w niej oświadczenie zezwalające witrynie C, i zdecydować się na jej wdrożenie.
Dalsze kroki
- Sprawdź, czy istnieje wyraźna dokumentacja Twojego przypadku użycia.
- Dowiedz się więcej o tworzeniu instrukcji
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2024-06-26 UTC.
[null,null,["Ostatnia aktualizacja: 2024-06-26 UTC."],[[["\u003cp\u003eDigital Asset Links enable apps and websites to make verifiable statements about their relationships with other apps and websites, such as link handling or credential sharing.\u003c/p\u003e\n"],["\u003cp\u003eThese statements are stored in a publicly accessible statement list, typically an "assetlinks.json" file hosted by the app or website making the statement.\u003c/p\u003e\n"],["\u003cp\u003eAndroid M and above automatically uses Digital Asset Links to verify website-to-app associations and direct links to the appropriate app if installed.\u003c/p\u003e\n"],["\u003cp\u003eThe protocol provides a foundation for trust and delegation between digital entities but relies on consumers to validate and act upon the statements.\u003c/p\u003e\n"]]],[],null,["# Getting Started\n\nOverview\n--------\n\nThe Digital Asset Links protocol and API enable an app or website to make public,\nverifiable *statements* about other apps or websites. For example, a website\ncan declare that it is associated with a specific Android app, or it can declare that\nit wants to share user credentials with another website.\n\nHere are some possible uses for Digital Asset Links:\n\n- Website A declares that links to its site should open in a designated app on mobile devices, if the app is installed.\n- Website A declares that it can share its Chrome user credentials with website B so that the user won't have to log in to website B if it is logged into website A.\n- App A declares that it can share device settings, such as location, with website B.\n\n### Key terms\n\n- **Principal:** The principal is the app or website making the statement. In Digital Asset Links, the principal is always the app or website that hosts the statement list.\n- **Statement list** : Statements are contained in a *statement list* that contains one or more statements. A statement list is cleartext and publicly accessible, in a location that is controlled by the principal and difficult to spoof or tamper with. It can be a free-standing file, or a section of another, larger item. For example, on a website, it is an entire file; in an Android app, it is a section in the app manifest. Statements can be viewed and verified by anyone, using non-proprietary methods. [See the statement list documentation for more information](/digital-asset-links/v1/create-statement).\n- **Statement:** A statement is a tightly structured JSON construct that consists of a *relation* (what the statement says to do, for example: Enable sharing credentials) and a *target* (the website or app that the relation applies to). Therefore, each statement is like a sentence, where *principal* says *relation* about *target* . \n- **Statement consumer:** A statement consumer requests a statement list from a principal, checks for the presence of a statement against a given principal, and if it exists, can perform the action specified. [See the statement comsuming documentation for more information](/digital-asset-links/v1/consuming)*.*\n\nQuick usage example\n-------------------\n\nHere's a very simplified example of how the website www.example.com could\nuse Digital Asset Links to specify that any links to URLs in that site should\nopen in a designated app rather than the browser:\n\n1. The website www.example.com publishes a statement list at https://www.example.com/.well-known/assetlinks.json. This is the official name and location for a statement list on a site; statement lists in any other location, or with any other name, are not valid for this site. In our example, the statement list consists of one statement, granting its Android app the permission to open links on its site: \n\n ```\n [{\n \"relation\": [\"delegate_permission/common.handle_all_urls\"],\n \"target\" : { \"namespace\": \"android_app\", \"package_name\": \"com.example.app\",\n \"sha256_cert_fingerprints\": [\"hash_of_app_certificate\"] }\n }]\n ```\n A statement list supports an array of statements within the \\[ \\] marks, but our example file contains only one statement. `sha256_cert_fingerprints` is the SHA256 fingerprints of your app's signing certificate. Find more details in the [Android App Links documentation](https://developer.android.com/training/app-links/verify-android-applinks#web-assoc).\n2. The Android app listed in the statement above has an intent filter that specifies the scheme, host, and path pattern of URLs that it wants to handle: in this case, https://www.example.com. The intent filter includes a special attribute `android:autoVerify`, new to Android M, which indicates that Android should verify the statement on the website described in the intent filter when the app is installed.\n3. A user installs the app. Android sees the intent filter with the `autoVerify` attribute and checks for the presence of the statement list at the specified site; if present, Android checks whether that file includes a statement granting link handling to the app, and verifies the app against the statement by certificate hash. If everything checks out, Android will then forward any https://www.example.com intents to the example.com app.\n4. The user clicks a link to https://www.example.com/puppies on their device. This link could be anywhere: in a browser, in a Google Search Appliance suggestion, or anywhere else. Android forwards the intent to the example.com app.\n5. The example.com app receives the intent and chooses to handle it, opening the puppies page in the app. If for some reason the app had declined to handle the link, or if the app were not on the device, then the link would have been sent to the next default intent handler matching that intent pattern (often the browser).\n\nImportant considerations and limitations:\n-----------------------------------------\n\n- The protocol does not authenticate the principal making the statement, but the statement is located in a specific location strongly associated with the principal, and under control of the principal.\n- The protocol does not authenticate the statement target, but it provides a means for the caller to authenticate the target (for example, a statement identifies mobile app targets by certificate hash and package name).\n- The protocol does not natively perform any statement actions; rather, it enables the ability to expose statements, which a consuming application must validate and then decide whether and how to act upon. Android M natively performs these steps for you; for example, if a website delegates link handling to a specific app, Android checks and verifies the statement, verifies the target app, and then offers the app the option to handle the given link.\n- The protocol does not enable making statements about two third parties: that is, website A can make a statement about website B, but website A cannot make a statement about website B's relationship to website C. However, if website B trusts website A, it can check website A for a statement granting permission to website C, and decide to implement that.\n\nNext steps\n----------\n\n1. [See if there is explicit documentation for your use case.](/digital-asset-links/v1/using)\n2. [Learn about creating a statement.](/digital-asset-links/v1/create-statement)"]]
