Синтаксис списка операторов

Список операторов — это файл или фрагмент в формате JSON, находящийся в известном месте.

Расположение списка заявлений

Информацию о том, где следует хранить этот список, см. в разделе Создание списка операторов .

Синтаксис

Список операторов или фрагмент представляет собой JSON-массив, содержащий один или несколько операторов веб-сайта или приложения в виде JSON-объектов. Эти операторы могут располагаться в любом порядке. Ниже представлен общий синтаксис:

[
  {
    "relation": ["relation_string"],
    "target": {target_object}
  } , ...
]

связь

Массив из одной или нескольких строк, описывающих объявляемое отношение к целевому объекту. См. список определённых строк отношения . Пример: delegate_permission/common.handle_all_urls

цель

Целевой актив, к которому относится это утверждение. Доступные типы целей:

• Целевой веб-сайт

  "target": {
    "namespace": "web",
    "site": "site_root_url"
  }

  пространство имен

  Должно быть web для веб-сайтов.

  сайт

  URI сайта, являющегося целью оператора, в формате http[s]://< hostname >[:< port >] , где <hostname> — полное имя, а <port> необходимо опустить при использовании порта 80 для HTTP или порта 443 для HTTPS. Целевым веб-сайтом может быть только корневой домен; ограничение на конкретный подкаталог невозможно; все каталоги в этом корне будут соответствовать. Поддомены не следует считать совпадающими: то есть, если файл оператора размещен на www.example.com, то www.puppies.example.com не следует считать совпадающим. Правила и примеры сопоставления целевых веб-сайтов см. в документации по целям . Пример: http://www.example.com

• Цель приложения Android

  "target": {
    "namespace": "android_app",
    "package_name": "fully_qualified_package_name",
    "sha256_cert_fingerprints": ["cert_fingerprint"]
  }

  пространство имен

  Для приложений Android должно быть android_app .

  имя_пакета

  Полное имя пакета приложения, к которому относится это утверждение. Пример: com.google.android.apps.maps .

  sha256_cert_fingerprints

  Отпечаток SHA265 сертификата приложения, к которому относится это утверждение, в верхнем регистре . Вы можете получить его с помощью openssl или Java keytool как показано здесь:

  • openssl x509 -in $CERTFILE -noout -fingerprint -sha256
  • keytool -printcert -file $CERTFILE | grep SHA256

  Пример: ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"] .

  Если вы используете функцию Play App Signing для своего приложения, то отпечаток сертификата, созданный локальным запуском keytool или openssl обычно не совпадает с отпечатком сертификата на устройствах пользователей. Вы можете проверить, используете ли вы функцию Play App Signing для своего приложения, в своей учётной записи разработчика Play Console в разделе Release > Setup > App Integrity . Если да, то на той же странице вы также найдёте правильный фрагмент JSON-кода Digital Asset Links для своего приложения.

relation_extensions (необязательно)

Вы можете добавить необязательное поле relation_extensions в оператор, чтобы предоставить дополнительную информацию о разрешениях и связях, которые вы хотите предоставить. Это поле должно быть объектом, где каждый ключ — строка отношения, а значение — объект, содержащий расширения для этого отношения. Клиенты, запрашивающие эти операторы, должны быть обновлены для поддержки этих полей.

Например, relation_extensions для отношения delegate_permission/common.handle_all_urls может выглядеть так:

  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": ["..."]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {...}
    }
  }
  

API DAL поддерживает возврат relation_extensions в вызовах API, если в запросе установлен параметр return_relation_extensions=true .

Пример списка утверждений

Вот пример списка заявлений о веб-сайте, который содержит заявления как о веб-сайтах, так и о приложениях: http://example.digitalassetlinks.org/.well-known/assetlinks.json

Масштабирование до десятков утверждений и более

В некоторых случаях принципал может захотеть сделать несколько разных заявлений о разных целевых объектах, или может возникнуть необходимость в том, чтобы разные принципалы опубликовали заявления для одного и того же набора целевых объектов. Например, веб-сайт может быть доступен на нескольких доменах верхнего уровня в каждой стране, и все они могут захотеть сделать заявление об одном и том же мобильном приложении.

В таких ситуациях могут быть полезны операторы include . Используя этот механизм, вы можете настроить указатели из множества различных субъектов на один центральный объект, где определяются операторы для всех субъектов.

Например, вы можете решить, что центральным местоположением будет `https://example.com/includedstatements.json`. Этот файл можно настроить так, чтобы он содержал тот же контент, что и в примерах выше.

Чтобы настроить указатель с веб-сайта на включаемый файл, измените `https://example.com/.well-known/assetlinks.json` на:

[{
  "include": "https://example.com/includedstatements.json"
}]

Чтобы настроить указатель из приложения Android на включаемый файл, измените `res/values/strings.xml` на:

<resources>
  ...
  <string name="asset_statements">
    [{
      \"include\": \"https://example.com/includedstatements.json\"
    }]
  </string>
</resources>

Дополнительная информация

Более подробное объяснение формата списка операторов и базовых концепций приведено в нашем документе спецификации .