В документе описывается, как приложение может получить разрешение на отправку запросов к API Tag Manager.
Авторизация запросов
Прежде чем пользователи смогут просмотреть информацию о своей учетной записи на любом сайте Google, они должны сначала войти в систему с помощью учетной записи Google. Аналогичным образом, при первом доступе к вашему приложению пользователям необходимо разрешить приложению доступ к их данным.
Каждый запрос, отправляемый вашим приложением к API Tag Manager, должен включать токен авторизации. Этот токен также идентифицирует ваше приложение для Google.
О протоколах авторизации
Для авторизации запросов ваше приложение должно использовать OAuth 2.0 . Другие протоколы авторизации не поддерживаются. Если ваше приложение использует вход через Google , некоторые аспекты авторизации обрабатываются автоматически.
Авторизация запросов с использованием OAuth 2.0
Все запросы к API Tag Manager должны быть авторизованы аутентифицированным пользователем.
Детали процесса авторизации, или «потока», для OAuth 2.0 несколько различаются в зависимости от типа разрабатываемого приложения. Следующий общий процесс применим ко всем типам приложений:
- При создании приложения вы регистрируете его через консоль Google API . Затем Google предоставляет информацию, которая понадобится вам позже, например, идентификатор клиента и секретный ключ клиента.
- Активируйте API Tag Manager в консоли Google API. (Если API не отображается в консоли API, пропустите этот шаг.)
- Когда вашему приложению требуется доступ к пользовательским данным, оно запрашивает у Google определенный объем доступа.
- Google отображает пользователю экран согласия , в котором ему предлагается разрешить вашему приложению запрашивать некоторые из его данных.
- Если пользователь одобрит запрос, Google предоставит вашему приложению кратковременный токен доступа .
- Ваше приложение запрашивает данные пользователя, прикрепляя к запросу токен доступа.
- Если Google определит, что ваш запрос и токен действительны, он вернет запрошенные данные.
Некоторые сценарии включают дополнительные шаги, например, использование токенов обновления для получения новых токенов доступа. Подробную информацию о сценариях для различных типов приложений см. в документации Google по OAuth 2.0 .
Вот информация об области действия OAuth 2.0 для API Tag Manager:
| Объем | Значение |
|---|---|
https://www.googleapis.com/auth/tagmanager.readonly | Просмотрите свои контейнеры Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.edit.containers | Управляйте контейнерами Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.delete.containers | Удалите контейнеры Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.edit.containerversions | Управляйте версиями контейнеров Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.publish | Опубликуйте свои контейнеры Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.manage.users | Управляйте правами доступа пользователей к данным Google Tag Manager. |
https://www.googleapis.com/auth/tagmanager.manage.accounts | Управляйте своими аккаунтами Google Tag Manager. |
Для запроса доступа с использованием OAuth 2.0 вашему приложению необходима информация об области действия, а также информация, которую Google предоставляет при регистрации вашего приложения (например, идентификатор клиента и секретный ключ клиента).
Начиная
Для начала работы с API Tag Manager необходимо воспользоваться инструментом настройки , который поможет вам создать проект в консоли Google API и включить API.
Для создания новой учетной записи службы выполните следующие действия:
- Нажмите «Создать учетные данные» > «Ключ учетной записи службы» .
- Выберите, следует ли загружать открытый/закрытый ключ учетной записи службы в виде стандартного файла P12 или в виде файла JSON, который может быть загружен клиентской библиотекой Google API.
Ваша новая пара открытого/закрытого ключей генерируется и загружается на ваш компьютер; она служит единственной копией этого ключа. Вы несете ответственность за его безопасное хранение.
Общие потоки OAuth 2.0
В следующих рекомендациях описаны типичные сценарии использования конкретных потоков OAuth 2.0:
Веб-сервер
Этот алгоритм хорошо подходит для автоматического/офлайн/планового доступа к учетной записи пользователя в Google Tag Manager.
- Автоматическое обновление информации Tag Manager с сервера.
На стороне клиента
Идеально подходит для случаев, когда пользователи взаимодействуют напрямую с приложением для доступа к своей учетной записи Google Tag Manager в браузере. Такой подход исключает необходимость в серверных возможностях, но делает его непрактичным для автоматизированной/офлайн/плановой отчетности.
- Настраиваемый инструмент конфигурации на основе браузера.
Установленные приложения
Для приложений, распространяемых в виде пакета и устанавливаемых пользователем, требуется, чтобы приложение или пользователь имели доступ к браузеру для завершения процесса аутентификации.
- Виджет рабочего стола на ПК или Mac.
- Плагин для системы управления контентом. Преимущество этого подхода по сравнению с веб-сервером или клиентской частью заключается в том, что для вашего приложения можно использовать один проект API Console. Это упрощает установку для пользователей.
Служебные аккаунты
Полезно для автоматического/автономного/запланированного доступа к вашей учетной записи Google Tag Manager. Например, для создания пользовательского инструмента для мониторинга вашей учетной записи Google Tag Manager и предоставления к ней доступа другим пользователям.
Поиск неисправностей
Если срок действия вашего access_token истек или вы используете неправильную область действия для конкретного вызова API, в ответе вы получите код состояния 401 .
Если у авторизованного пользователя нет доступа к учетной записи или контейнеру Google Tag Manager, в ответе вы получите код состояния 403 Убедитесь, что вы авторизованы под правильным пользователем и что вам предоставлены разрешения на доступ к учетной записи или контейнеру Tag Manager.
Игровая площадка OAuth 2.0
OAuth 2.0 Playground позволяет пройти весь процесс авторизации через веб-интерфейс. Инструмент также отображает все заголовки HTTP-запроса, необходимые для выполнения авторизованного запроса. Если у вас не получается настроить авторизацию в собственном приложении, попробуйте сделать это через OAuth 2.0 Playground. Затем вы можете сравнить заголовки HTTP и запрос из Playground с тем, что отправляет ваше приложение. Эта проверка — простой способ убедиться в правильности форматирования ваших запросов.
Недействительный грант
Если при попытке использовать токен обновления вы получаете сообщение об ошибке invalid_grant , причиной ошибки может быть одна или обе из следующих причин:
- Часы вашего сервера не синхронизированы с NTP .
- Вы превысили лимит токенов обновления.
Приложения могут запрашивать несколько токенов обновления для доступа к одной учетной записи Google Tag Manager. Например, это полезно в ситуациях, когда пользователь хочет установить приложение на несколько компьютеров и получить доступ к одной и той же учетной записи Google Tag Manager. В этом случае требуется два токена обновления, по одному для каждой установки. Когда количество токенов обновления превышает лимит, старые токены становятся недействительными. Если приложение пытается использовать недействительный токен обновления, возвращается ошибкаinvalid_grant. Каждая уникальная комбинация идентификатора клиента/учетной записи может иметь до 25 токенов обновления. (Обратите внимание, что этот лимит может быть изменен.) Если приложение продолжает запрашивать токены обновления для той же комбинации идентификатора клиента/учетной записи, после выдачи 26-го токена первый выданный токен обновления становится недействительным. 27-й запрошенный токен обновления делает недействительным второй выданный токен, и так далее.