Начиная

Обзор

Протокол Digital Asset Links и API позволяют приложению или веб-сайту публиковать проверяемые заявления о других приложениях или веб-сайтах. Например, веб-сайт может объявить, что он связан с определенным приложением Android, или он может объявить, что хочет поделиться учетными данными пользователя с другим веб-сайтом.

Вот несколько возможных вариантов использования ссылок на цифровые активы:

  • Веб-сайт А заявляет, что ссылки на его сайт должны открываться в специальном приложении на мобильных устройствах, если оно установлено.
  • Веб-сайт A заявляет, что он может делиться своими учетными данными пользователя Chrome с веб-сайтом B, чтобы пользователю не приходилось входить на веб-сайт B, если он вошел на веб-сайт A.
  • Приложение А заявляет, что оно может делиться настройками устройства, такими как местоположение, с веб-сайтом Б.

Ключевые термины

  • Принципал: Принципал — это приложение или веб-сайт, делающий заявление. В Digital Asset Links принципалом всегда является приложение или веб-сайт, на котором размещен список выписок.
  • Список операторов. Операторы содержатся в списке операторов , содержащем одно или несколько операторов. Список операторов является открытым текстом и общедоступен, находится в месте, контролируемом принципалом, и его трудно подделать или подделать. Это может быть отдельный файл или часть другого, более крупного файла. Например, на веб-сайте это целый файл; в приложении для Android это раздел в манифесте приложения. Заявления могут быть просмотрены и проверены кем угодно с использованием незапатентованных методов. Дополнительную информацию см. в документации по списку операторов .
  • Утверждение. Утверждение — это строго структурированная конструкция JSON, состоящая из отношения (что в утверждении говорится делать, например: Разрешить совместное использование учетных данных) и цели (веб-сайт или приложение, к которому относится отношение). Следовательно, каждое утверждение похоже на предложение, в котором принципал говорит об отношении к цели .
  • Потребитель операторов: потребитель операторов запрашивает список операторов у принципала, проверяет наличие оператора для данного принципала и, если он существует, может выполнить указанное действие. Дополнительную информацию см. в документации по использованию оператора .

Пример быстрого использования

Вот очень упрощенный пример того, как веб-сайт www.example.com может использовать ссылки на цифровые активы, чтобы указать, что любые ссылки на URL-адреса на этом сайте должны открываться в указанном приложении, а не в браузере:

  1. Веб-сайт www.example.com публикует список заявлений по адресу https://www.example.com/.well-known/assetlinks.json. Это официальное название и место для списка заявлений на сайте; списки утверждений в любом другом месте или с любым другим именем недействительны для этого сайта. В нашем примере список операторов состоит из одного оператора, предоставляющего приложению Android разрешение открывать ссылки на своем сайте:
    [{
      "relation": ["delegate_permission/common.handle_all_urls"],
      "target" : { "namespace": "android_app", "package_name": "com.example.app",
                   "sha256_cert_fingerprints": ["hash_of_app_certificate"] }
    }]
    Список операторов поддерживает массив операторов, заключенных в метки [ ], но файл нашего примера содержит только один оператор. . sha256_cert_fingerprints — это отпечатки SHA256 сертификата подписи вашего приложения. Дополнительные сведения см. в документации Android App Links .
  2. Приложение для Android, указанное в приведенном выше заявлении, имеет фильтр намерений, который указывает схему, узел и шаблон пути URL-адресов, которые оно хочет обрабатывать: в данном случае https://www.example.com. Фильтр намерений включает специальный атрибут android:autoVerify , новый для Android M, который указывает, что Android должен проверить утверждение на веб-сайте, описанное в фильтре намерений, при установке приложения.
  3. Пользователь устанавливает приложение. Android видит фильтр намерений с атрибутом autoVerify и проверяет наличие списка операторов на указанном сайте; если он присутствует, Android проверяет, содержит ли этот файл оператор, предоставляющий обработку ссылки на приложение, и сверяет приложение с оператором по хэшу сертификата. Если все в порядке, Android перенаправит все намерения https://www.example.com в приложение example.com.
  4. Пользователь щелкает ссылку https://www.example.com/puppies на своем устройстве. Эта ссылка может быть где угодно: в браузере, в предложении Google Search Appliance или где-либо еще. Android перенаправляет намерение в приложение example.com.
  5. Приложение example.com получает намерение и решает обработать его, открывая страницу щенков в приложении. Если бы по какой-то причине приложение отказалось обрабатывать ссылку или если бы приложение не было на устройстве, тогда ссылка была бы отправлена ​​следующему обработчику намерений по умолчанию, соответствующему этому шаблону намерения (часто браузеру).

Важные соображения и ограничения:

  • Протокол не аутентифицирует принципала, делающего оператор, но оператор находится в определенном месте, прочно связанном с принципалом и находящемся под его контролем.
  • Протокол не выполняет проверку подлинности целевого объекта инструкции, но предоставляет вызывающей стороне средства для проверки подлинности целевого объекта (например, оператор идентифицирует целевые объекты мобильного приложения по хэшу сертификата и имени пакета).
  • Протокол изначально не выполняет никаких действий с операторами; скорее, он дает возможность выставлять операторы, которые приложение-потребитель должно проверять, а затем решать, следует ли и как действовать в соответствии с ними. Android M изначально выполняет эти шаги за вас; например, если веб-сайт делегирует обработку ссылки определенному приложению, Android проверяет и проверяет оператор, проверяет целевое приложение, а затем предлагает приложению возможность обработки данной ссылки.
  • Протокол не позволяет делать заявления о двух третьих сторонах: то есть веб-сайт А может сделать заявление о веб-сайте Б, но веб-сайт А не может сделать заявление об отношении веб-сайта Б к веб-сайту С. Однако, если веб-сайт Б доверяет веб-сайту А, он может проверить веб-сайт A на наличие заявления, предоставляющего разрешение веб-сайту C, и принять решение о его реализации.

Следующие шаги

  1. Посмотрите, есть ли подробная документация для вашего варианта использования.
  2. Узнайте о создании заявления.