Авторизация API Менеджера тегов

В документе описывается, как приложение может получить авторизацию для выполнения запросов к API диспетчера тегов.

Авторизация запросов

Прежде чем пользователи смогут просматривать информацию своей учетной записи на любом сайте Google, они должны сначала войти в систему с учетной записью Google. Точно так же, когда пользователи впервые получают доступ к вашему приложению, им необходимо авторизовать ваше приложение для доступа к их данным.

Каждый запрос, который ваше приложение отправляет в API Диспетчера тегов, должен включать токен авторизации. Токен также идентифицирует ваше приложение для Google.

О протоколах авторизации

Ваше приложение должно использовать OAuth 2.0 для авторизации запросов. Другие протоколы авторизации не поддерживаются. Если ваше приложение использует «Войти через Google» , некоторые аспекты авторизации выполняются за вас.

Авторизация запросов с помощью OAuth 2.0

Все запросы к API Диспетчера тегов должны быть авторизованы авторизованным пользователем.

Детали процесса авторизации или «потока» для OAuth 2.0 несколько различаются в зависимости от того, какое приложение вы пишете. Следующий общий процесс применим ко всем типам приложений:

  1. Когда вы создаете свое приложение, вы регистрируете его с помощью консоли Google API . Затем Google предоставляет информацию, которая понадобится вам позже, например идентификатор клиента и секрет клиента.
  2. Активируйте API Диспетчера тегов в консоли Google API. (Если API не указан в консоли API, пропустите этот шаг.)
  3. Когда вашему приложению требуется доступ к пользовательским данным, оно запрашивает у Google определенный объем доступа.
  4. Google отображает пользователю экран согласия , прося его разрешить вашему приложению запрашивать некоторые его данные.
  5. Если пользователь одобряет, Google предоставляет вашему приложению кратковременный токен доступа .
  6. Ваше приложение запрашивает пользовательские данные, прикрепляя к запросу токен доступа.
  7. Если Google определит, что ваш запрос и токен действительны, он вернет запрошенные данные.

Некоторые потоки включают дополнительные шаги, например использование токенов обновления для получения новых токенов доступа. Подробную информацию о потоках для различных типов приложений см. в документации Google OAuth 2.0 .

Вот информация об области действия OAuth 2.0 для API Диспетчера тегов:

Объем Значение
https://www.googleapis.com/auth/tagmanager.readonly Просмотрите контейнеры Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.edit.containers Управляйте контейнерами Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.delete.containers Удалите контейнеры Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.edit.containerversions Управляйте версиями контейнеров Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.publish Опубликуйте контейнеры Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.manage.users Управляйте разрешениями пользователей для данных Диспетчера тегов Google.
https://www.googleapis.com/auth/tagmanager.manage.accounts Управляйте своими учетными записями Диспетчера тегов Google.

Чтобы запросить доступ с помощью OAuth 2.0, вашему приложению необходима информация об области действия, а также информация, которую Google предоставляет при регистрации вашего приложения (например, идентификатор клиента и секрет клиента).

Начиная

Чтобы начать использовать API Диспетчера тегов, вам необходимо сначала воспользоваться инструментом настройки , который поможет вам создать проект в консоли Google API, включить API и создать учетные данные.

Чтобы настроить новую учетную запись службы, выполните следующие действия:

  1. Нажмите Создать учетные данные > Ключ служебной учетной записи .
  2. Выберите, следует ли загружать открытый/закрытый ключ сервисного аккаунта в виде стандартного файла P12 или в виде файла JSON, который можно загрузить с помощью клиентской библиотеки API Google.

Ваша новая пара открытого/закрытого ключей генерируется и загружается на ваш компьютер; он служит единственной копией этого ключа. Вы несете ответственность за его безопасное хранение.

Общие потоки OAuth 2.0

В следующих рекомендациях описаны общие случаи использования конкретных потоков OAuth 2.0:

Веб сервер

Этот процесс хорош для автоматического/автономного/запланированного доступа к учетной записи Google Tag Manager пользователя.

Пример:
  • Автоматическое обновление информации Диспетчера тегов с сервера.

Сторона клиента

Идеально подходит для случаев, когда пользователи напрямую взаимодействуют с приложением для доступа к своей учетной записи Диспетчера тегов Google в браузере. Этот поток устраняет необходимость в возможностях на стороне сервера, но также делает непрактичным создание автоматических, автономных и запланированных отчетов.

Пример:
  • Настраиваемый инструмент настройки на основе браузера.

Установленные приложения

Для приложений, которые распространяются в виде пакета и устанавливаются пользователем. Для завершения процесса аутентификации требуется, чтобы приложение или пользователь имели доступ к браузеру.

Примеры:
  • Виджет рабочего стола на ПК или Mac.
  • Плагин для системы управления контентом. Преимущество этого процесса по сравнению с веб-сервером или на стороне клиента заключается в том, что для вашего приложения можно использовать один проект консоли API. Это упрощает установку для пользователей.

Сервисные аккаунты

Полезно для автоматического/офлайн/запланированного доступа к вашей учетной записи Google Tag Manager. Например, создать собственный инструмент для мониторинга вашей собственной учетной записи Диспетчера тегов Google и поделиться им с другими пользователями.

Поиск неисправностей

Если срок действия вашего access_token истек или вы используете неверную область действия для определенного вызова API, вы получите в ответе код состояния 401 .

Если авторизованный пользователь не имеет доступа к учетной записи или контейнеру Диспетчера тегов Google, вы получите в ответ код состояния 403 . Убедитесь, что вы авторизованы под правильным пользователем и что вам предоставлены разрешения на доступ к аккаунту или контейнеру Диспетчера тегов.

Игровая площадка OAuth 2.0

OAuth 2.0 Playground позволяет вам пройти весь процесс авторизации через веб-интерфейс. Инструмент также отображает все заголовки HTTP-запросов, необходимые для выполнения авторизованного запроса. Если вы не можете получить авторизацию для работы в своем приложении, попробуйте заставить его работать через OAuth 2.0 Playground. Затем вы можете сравнить HTTP-заголовки и запросы с игровой площадки с тем, что отправляет ваше приложение. Эта проверка — простой способ убедиться, что вы правильно форматируете свои запросы.

Неверный грант

Если вы получаете ответ об invalid_grant при попытке использовать токен обновления, ошибка может быть вызвана одной или обеими из следующих причин:

  1. Часы вашего сервера не синхронизированы с NTP .
  2. Вы превысили лимит токена обновления.
    Приложения могут запрашивать несколько токенов обновления для доступа к одной учетной записи Диспетчера тегов Google. Например, это полезно в ситуациях, когда пользователь хочет установить приложение на несколько компьютеров и получить доступ к одной и той же учетной записи Диспетчера тегов Google. В этом случае требуются два токена обновления, по одному для каждой установки. Когда количество токенов обновления превышает лимит, старые токены становятся недействительными. Если приложение пытается использовать недействительный токен обновления, возвращается ответ об invalid_grant . Каждая уникальная комбинация идентификатора клиента и учетной записи может иметь до 25 токенов обновления. (Обратите внимание, что это ограничение может быть изменено.) Если приложение продолжает запрашивать токены обновления для той же комбинации идентификатора клиента и учетной записи, то после выдачи 26-го токена первый выданный токен обновления становится недействительным. 27-й запрошенный токен обновления делает недействительным 2-й выданный токен и так далее.