Действия в Google - процесс привязки аккаунта достигает URL-адреса токена перед авторизацией URL-адреса? - PullRequest
0 голосов
/ 05 ноября 2018

Мы пытаемся поддержать «традиционный» поток привязки учетных записей, так как он кажется наиболее универсальным, дает нам шанс выявить условия и положения, и мы подумали, что он будет наиболее подходящим.

Но тестирование в мобильном приложении Assistant для начинающих не удается для большинства пользователей в нашем приложении Actions в Dev - после того, как пользователь видит всплывающее окно, управляемое Google, в приложении Assistant с опцией «ССЫЛКИ ССЫЛКИ» - Они нажимают эту опцию, и наш экран авторизации не появляется.

Служба поддержки действий взглянула на нашу конфигурацию привязки аккаунта и не видит никаких проблем.

Несколько тестовых пользователей с новыми телефонами Android видят наш Экран авторизации, но большинство не видят.

Если мы проверяем URL-адрес авторизации, вставляя его в браузер на одном устройстве - он всегда отображается нормально.

Что странно - если мы посмотрим в журналах нашего веб-сервера во время неудачных случаев , мы увидим только попадания на наш «TOKEN URL», тогда как мое понимание новый пользователь должен получить доступ к нашему «URL авторизации», прежде чем он попадет в токен. Успешные случаи ДЕЙСТВИТЕЛЬНО попадают на наш URL авторизации, как и ожидалось.

Не стесняйтесь, если кто-нибудь может ответить на ЛЮБОЕ из следующего:

Есть идеи, что может быть причиной проблем здесь?

Или как мы могли бы исследовать глубже?

Должно ли приложение проходить альфа-тестирование или что-то подобное, прежде чем будет работать привязка аккаунта?

Это нормально / ожидается попадание на токен URL для пользователя, который никогда не связывал аккаунты?

Может ли кто-нибудь подтвердить, каким должен быть ответ получения токена в этом случае? (Может быть, мы не отвечаем таким образом, который удовлетворяет другой конец)

У кого-нибудь есть фиктивная / HelloWorld учетная запись, связывающая конечную точку сети, с которой мы могли бы проверить? (Боже, это было бы удобно для сообщества разработчиков!)

1 Ответ

0 голосов
/ 05 ноября 2018

Я не знаю точно, что происходит, но есть несколько подсказок о том, что происходит и какой путь расследовать. Я предполагаю, что вы делаете привязку аккаунта только с OAuth. Если вы используете комбинацию «Google Sign In for Assistant и OAuth», это может изменить некоторые вещи. Чтобы ответить на некоторые ваши вопросы:

Что может заставить помощника перейти к конечной точке токена вместо конечной точки аутентификации?

Он не пошел бы к конечной точке токена, если у него уже не было токена. Я мог бы подумать о нескольких возможных сценариях:

  • Если он собирался в Auth, получить токен, так как он уже был авторизован, поэтому окно не всплывало. (Но вы указали, что не перейдете на эту страницу.)

  • Если соответствующая учетная запись уже авторизована для проекта другими способами. Вы можете проверить https://myaccount.google.com/permissions, чтобы увидеть, авторизован ли он уже.

  • Если вы проверяли его с этой учетной записью ранее, и у него есть токен с того времени. Если это так, он должен быть указан в https://myaccount.google.com/permissions. Вероятно.

  • Если вы не используете учетную запись, которую, по вашему мнению, используете на данном устройстве.

Как это расследовать?

Как только вы дважды проверите некоторые из наиболее очевидных вещей (используя правильный аккаунт?):

  • Посмотрите, что отправляется на конечную точку токена
    • Токен выглядит знакомым? То же самое между звонками? Одинаково между разными аккаунтами?
    • Вы регистрируете токены, которые выдаются? Вы можете?
    • А как насчет другой информации, отправляемой вместе с токеном, такой как client_id и client_secret?

Должен ли он быть в Альфе?

Я не уверен. Последний раз я проверял, это не так. Я думаю, что он больше не работает в симуляторе, что раздражает, но не требует присутствия в Альфе.

Однако это немного усложняет проверку, так как нет страницы Справочника, которая могла бы сообщить вам, была ли учетная запись уже связана. Вам нужно будет перейти к списку связанных приложений для учетной записи, чтобы удалить приложение, если оно: https://myaccount.google.com/permissions

Это нормально?

Я бы так не думал. Он не должен попадать в конечную точку токена, если у него нет кода авторизации или токена обновления для обмена. Он должен иметь этот код / ​​токен откуда-то.

Как вы должны ответить?

Если вы получите недействительный код авторизации или токен обновления или любая другая информация, предоставленная в конечной точке токена, не соответствует ожидаемой, вы должны вернуть код ошибки HTTP 400 "Плохо Запрос "и включите в качестве тела JSON

{"error": "invalid_grant"}

Этот должен заставить его пройти через пользователь с реаутом.

Есть ли публичный тестовый сервер?

Auth0 не является общедоступным, но бесплатен для базового использования и хорошо подходит для тестовых целей.

...