Это приложение хотело бы: Иметь автономный доступ, когда access_type=online

У меня есть приложение Google с аутентификацией OAuth 2.0. Раньше все работало нормально, но недавно я начал получать следующий экран «Запрос на разрешение»:

введите здесь описание изображения

Странно то, что я получаю этот экран, когда прохожу access_type=online. Опять же, это работало до недавнего времени.

Что может быть причиной этого? ТИА

Изменить:

Запрашиваемые области:

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile

Я уже пробовал:

  • с access_type=online и без
  • с approval_prompt=auto и без

Изменить №2:

Это код Python, который я использую для создания URL-адреса аутентификации:

encoded_params = urllib.urlencode({
    "response_type" : "code",
    "client_id" : MY_CLIENT_ID,
    "scope" : " ".join(MY_SCOPES),
    "redirect_uri" : MY_REDIRECT_URI,
    "state" : random_security_token,
    "access_type" : "online",
    "approval_prompt" : "auto",
    })

auth_url = "https://accounts.google.com/o/oauth2/auth?" + encoded_params

Обновление (14 октября):

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


oauth-2.0 google-oauth
person Tzach    schedule 28.01.2014    source источник
comment
Как вы запрашиваете разрешения oauth2? У вас есть приложение, которое можно запустить с предварительной аутентификацией с Google Диска, или оно автономно с помощью API? Если последнее, можете ли вы добавить код авторизации в вопрос?   -  person daw    schedule 04.02.2014
comment
@daw Я использую python и вручную генерирую URL-адрес аутентификации, см. внесенные мной изменения.   -  person Tzach    schedule 04.02.2014
comment
хм - выглядит нормально. Я запрашиваю те же области и получаю это нежелательное приглашение при запуске с диска Google. Сами Google добавляют access_type: offline к URL-адресу, который они создают. Интересно, это потому, что адрес электронной почты доступен в автономном режиме, поэтому они переопределяют access_type?   -  person daw    schedule 04.02.2014
comment
@Tzach, где ты можешь решить свою проблему? У меня такая же проблема, и я не могу найти решение.   -  person Ioannis Tzikas    schedule 31.03.2015
comment
@IoannisTzikas Нет, извини.   -  person Tzach    schedule 31.03.2015
comment
Ваш redirect_url содержит localhost? У меня тоже была эта проблема. Я изменил redirect_url на адрес общедоступного домена, и на данный момент эта проблема устранена. Я не собирался воспроизводить ошибку (пока). Не уверен, что это было действительное исправление.   -  person infrared    schedule 29.04.2015
comment
@инфракрасный ДА. Он работает на моем производственном сайте без «localhost» в redirect_url. Он по-прежнему показывает экран согласия, когда я запускаю свое приложение на своем компьютере с помощью «localhost». Спасибо.   -  person brian    schedule 29.04.2015
comment
Возможный дубликат Приложение продолжает запрашивать разрешение на Есть автономный доступ, зачем?   -  person Chris Moschini    schedule 06.09.2016

Ответы (9)


arrow_upward
28
arrow_downward

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

Решение состоит в том, чтобы отозвать токены, когда вы закончите с ними (либо при выходе пользователя из системы, либо сразу после аутентификации пользователя), выполнив этот запрос:

https://accounts.google.com/o/oauth2/revoke?token={token}

Вам не нужно предоставлять какие-либо учетные данные приложения, только токен в качестве аргумента URL.

(документы здесь https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke)

У меня была та же проблема, и никакая комбинация значений access_type или approval_prompt, похоже, не решила ее. Отзыв токена помог.

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

https://security.google.com/settings/security/permissions
person amwinter    schedule 25.03.2015
comment
Спасибо! Это сэкономило мне много пустых циклов :). Последняя ссылка в вашем посте помогла - person Shreyas; 25.08.2015

arrow_upward
19
arrow_downward

ОБНОВЛЕНИЕ:

Область действия электронной почты теперь

email

Устаревшие API Google+ были отключены 7 марта 2019 года. Области, ранее запрашиваемые вашими приложениями, теперь могут быть устаревшими или недействительными. Разработчикам следует обновить свой код, чтобы удалить или обновить ссылки на Google+, API Google+ и любые связанные области действия OAuth. источник: https://developers.google.com/+/scopes-shutdown

-- СТАРЫЙ ОТВЕТ --

Недавно Google изменил область действия электронной почты. Вы должны заменить

https://www.googleapis.com/auth/userinfo.email

с участием:

https://www.googleapis.com/auth/plus.profile.emails.read

а также:

https://www.googleapis.com/auth/plus.login

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

Смотрите также:

https://developers.google.com/+/api/oauth#email

Предупреждение: эта область устарела. Google больше не будет поддерживать эту область после 1 сентября 2014 года. Подробнее см. в разделе Переход на вход в Google+.

Это также изменяет способ получения адреса электронной почты:

https://developers.google.com/+/api/auth-migration#email

Также имейте в виду, что вам необходимо активировать API Google+ в консоли управления, чтобы это работало.

person dominik    schedule 20.05.2014
comment
Отличный ответ, спасибо! На самом деле новые области должны быть email и profile, поскольку они эквивалентны областям, запрошенным в вопросе. - person Tzach; 21.05.2014
comment
Я рад, что смог помочь. - person dominik; 21.05.2014
comment
Хм, я использую профиль электронной почты в качестве строки области действия, но все еще получаю запрос на разрешение для автономного доступа. Что действительно странно, это происходит только из интеграционных тестов, а не вручную. Я использую одну и ту же серверную среду и использую одни и те же учетные данные Google в обоих случаях. - person Frank Schwieterman; 31.07.2014
comment
Хм странно. Мне помогла настройка:approval_prompt to auto, но я думаю, вы уже пробовали это. - person dominik; 05.08.2014
comment
Похоже, что они по-прежнему будут поддерживать userinfo.email, хотя и устарели (я больше не вижу этого предупреждения, только это в руководстве по миграции: Устарело и будет поддерживаться и оставаться доступным для обратной совместимости. Google продолжит генерировать новые токены. с этими областями. - person UpTheCreek; 26.08.2014
comment
Предложение @dominik верное. Я сделал автоматический запрос утверждения_подсказки, а запрос на доступ в автономном режиме отключен. - person mujaffars; 17.03.2015
comment
предупреждение: для учетных записей, у которых не включена G+, область https://.../plus.login предлагает им настроить G+ и завершается ошибкой, если они отменяют. - person amwinter; 26.03.2015
comment
Я получаю сообщение об ошибке «Ошибка: invalid_scope», когда пытаюсь использовать области «plus.login» и «plus.profile.emails.read» вместо «профиль» и «электронная почта». - person IanB; 02.04.2015
comment
Кажется, нет решения для этого с помощью мобильных приложений? approval_prompt недоступен в приложениях. Новые прицелы email и profile не работают! И устаревшая область не работает должным образом, если у пользователей не включена G+. - person User; 03.03.2016

arrow_upward
18
arrow_downward

Использование http://localhost в параметре redirect_url запроса OAuth приведет к тому, что пользователю будет предложено предоставить автономный доступ при первой аутентификации после каждого входа в систему.

person Ian Mackinnon    schedule 06.07.2015
comment
Спасибо. Это где-то задокументировано? Есть ли причина такого поведения? - person Tzach; 06.07.2015
comment
Не то, чтобы я мог видеть. Это просто мой опыт проб и ошибок. Также поведение localhost упоминается в куче вопросов: stackoverflow.com/questions/20555351/ stackoverflow.com/questions/28957654 / stackoverflow.com/questions/28052155/ - person Ian Mackinnon; 06.07.2015

arrow_upward
5
arrow_downward

Цах. Чтобы не запрашивать экран согласия после первого входа в систему. Это может понадобиться для передачи значения функции:

$client->setApprovalPrompt("авто");

person CK Tan    schedule 29.01.2014
comment
Уже пробовал. Пожалуйста, прочитайте вопрос и другие ответы. - person Tzach; 29.01.2014

arrow_upward
1
arrow_downward

Я думаю, что на этот вопрос был дан ответ, но я не могу найти ссылку прямо сейчас.

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

approval_prompt=auto

чтобы избежать подсказки

person pinoyyid    schedule 28.01.2014
comment
Спасибо, но в чем причина запрашивать автономный доступ, когда я специально запрашиваю онлайн-доступ? Это может запутать пользователя и даже помешать ему разрешить доступ. - person Tzach; 29.01.2014
comment
Я согласен, и это несколько раз поднималось в Google. В вашем случае основное внимание уделяется тому, чтобы ваше приложение вообще не запрашивало. - person pinoyyid; 29.01.2014
comment
Кстати, у меня уже есть approval_prompt=auto в запросе, и я все еще получаю экран подсказки. - person Tzach; 29.01.2014

arrow_upward
1
arrow_downward

У меня была такая же проблема. Хотя я не ставил

access_type=online

Однако, как я понимаю, по умолчанию

access_type

is 

online

От: https://developers.google.com/identity/protocols/OAuth2WebServer: «Стиль доступа по умолчанию называется онлайн».

Что решило это для меня, так это удалить:

prompt=consent

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

Я полагаю, что параметр приглашения предназначен для замены параметра утверждения_подсказки. Но похоже, что если я установлю для него значение «согласие», это должно просто означать, что я хочу, чтобы каждый раз отображался обычный экран согласия, а не экран согласия «автономного доступа». Документы здесь: https://developers.google.com/identity/protocols/OpenIDConnect#prompt, кажется, не опровергает это мнение, поэтому я не уверен, почему он ведет себя таким образом. Но, по крайней мере, я смог заставить его работать так, как я хочу, на данный момент.

person Paul Brackin    schedule 23.03.2017

arrow_upward
0
arrow_downward

Ну, я не знаю, является ли это на самом деле ответом, но я обнаружил, что некоторые пользователи видят:

«Иметь автономный доступ»

по сравнению с другими (которые получают то, что, я думаю, вы хотите видеть):

«Просмотреть основную информацию о вашей учетной записи»

person jmazin    schedule 06.02.2014
comment
Дело в том, что я получаю этот экран, хотя я уже одобрил приложение когда-то в прошлом. Это как дополнительное одобрение. - person Tzach; 06.02.2014
comment
Хммм, может это как-то связано с заменой approval_prompt на prompt? (developers.google.com/accounts/docs/OAuth2Login#prompt) - person jmazin; 06.02.2014

arrow_upward
-1
arrow_downward

Вы используете клиентскую библиотеку API Google?

https://developers.google.com/api-client-library/

Он устанавливает для access_type значение «автономно» при самостоятельном обновлении токенов.

В версии Python я изменил строку 1204 файла oauth2client/client.py.

от

    'access_type': 'offline',

to

    'access_type': 'online',

и теперь работает корректно.

person M M    schedule 05.01.2015
comment
Я не использую эту библиотеку, см. вопрос о точном коде, который генерирует URL-адрес. - person Tzach; 05.01.2015

arrow_upward
-2
arrow_downward

Я применил все в этом вопросе. В моем случае сработала только очистка куки.

person fatihpense    schedule 31.12.2015