Начало работы

Обзор

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

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

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

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

  • Принципал: Принципал – это приложение или веб-сайт, делающий заявление. В 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 .
  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 может делать заявления о веб-сайте B, но веб-сайт A не может делать заявления о связи веб-сайта B с веб-сайтом C. Однако, если веб-сайт B доверяет веб-сайту A, он может проверить веб-сайт A на предмет заявления, предоставляющего разрешение веб-сайту C, и принять решение реализовать его.

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

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