Google OAuth 2.0 офлайн достъп

Приложението ми има нужда от достъп до данните на потребителя дори когато потребителят не присъства. Така че моята заявка за код за оторизация включва access_type=offline, което означава, че ще получа обратно токен за опресняване, ако това е първият път, когато потребителят удостоверява приложението ми. Запазвам маркера за опресняване и го използвам по-късно.

Всичко работи според очакванията и доста добре. Но това, което ме притеснява, е изявление в документацията:

Имайте предвид, че има ограничения за броя на токените за опресняване, които ще бъдат издадени; едно ограничение за комбинация клиент/потребител и друго за използване във всички клиенти. Трябва да запазите маркерите за опресняване в дългосрочно хранилище и да продължите да ги използвате, докато остават валидни. Ако вашето приложение изисква твърде много токени за опресняване, то може да навлезе в тези ограничения, в който случай по-старите токени за опресняване ще спрат да работят.

Ако разбирам това правилно, възможно е маркерът за опресняване, който запазвам, да стане невалиден, ако потребителят разреши твърде много приложения?! Дали това е правилно? Как трябва да реагира приложението в такива ситуации? Да поискате друг маркер за опресняване?

Благодаря предварително.

РЕДАКТИРАНЕ: Създадох тестов PHP скрипт, който иска токени за опресняване от 4 клиента на Google (под клиент имам предвид генерирани идентификационни данни в конзолата за разработка). Три от тях са свързани с един gmail адрес, а четвъртият с различен. За първия имейл генерирах 2 проекта и за първия проект генерирах 2 идентификатора на клиента. Така:

  1. имейл X, проект A, клиентски номер abc
  2. имейл X, проект A, клиентски номер def
  3. имейл X, проект B, клиентски номер mno
  4. имейл Y, проект C, клиентски номер xyz

Започнах теста, като поисках токен за опресняване за всеки клиент. След това поисках още 24 токена за опресняване за първия идентификатор на клиента abc. В този момент всички токени за опресняване бяха валидни, въпреки че за имейл X имах 27 токена за опресняване. След това, когато поисках друг токен за опресняване за клиент с идентификатор abc, първият за този клиент беше анулиран, така че достигнах ограничението от 25 токена за комбинация имейл/клиент. Всички други токени бяха все още валидни и успях да генерирам нови токени за клиент def. Този клиент е за същия проект A и същия имейл X. Така че не мога да достигна втората граница. Какво означават тези твърдения, все още е пълна мистерия за мен:

https://developers.google.com/accounts/docs/OAuth2#expiration

Ако трябва да упълномощите множество програми, машини или устройства, едно решение е да ограничите броя на клиентите, които упълномощавате за потребителски акаунт, до 15 или 20. Ако сте администратор на Google Apps, можете да създадете допълнителни администраторски потребители и да ги използвате да упълномощи някои от клиентите.

https://developers.google.com/accounts/docs/OAuth2WebServer#refresh

Имайте предвид, че има ограничения за броя на токените за опресняване, които ще бъдат издадени; едно ограничение за комбинация клиент/потребител и друго за потребител за всички клиенти.


oauth-2.0 google-oauth
person Martin Dimitrov    schedule 09.04.2014    source източник
comment
Получих съобщение от един от разработчиците на Google: Не съм сигурен какъв е лимитът за потребител за всички клиенти, но не съм чувал някой да е удрял това преди. ако разбера ще ви уведомя. Така че все още чакаме официална информация какво означава това.   -  person DaImTo    schedule 16.04.2014
comment
@DaImTo Благодаря. Аз самият също не мога да достигна други ограничения. Но винаги е по-добре да знаете със сигурност. Благодаря отново.   -  person Martin Dimitrov    schedule 16.04.2014

Отговори (1)


arrow_upward
3
arrow_downward

Всъщност не е толкова лошо, колкото си мислите. Токените за опресняване са специфични за приложението, което означава, че са специфични за вашия клиентски идентификатор. Ако потребителят инсталира вашето приложение няколко пъти, той има определен брой токени за опресняване, свързани с вашето приложение.

Сблъсках се с този проблем с SSIS Connection Manager, ако потребителят е имал моя мениджър на връзки, работещ на повече от 20 SSIS пакета, първият инсталиран ще спре да работи.

https://developers.google.com/accounts/docs/OAuth2#expiration

Token expiration

You should write your code to anticipate the possibility that a granted token might
no longer work. 
A token might stop working for one of these reasons:
  • Потребителят е отменил достъпа.
  • Токенът не е използван шест месеца.
  • Потребителският акаунт е надхвърлил определен брой заявки за токени.

Понастоящем има ограничение от 25 токена на потребителски акаунт в Google. Ако даден потребителски акаунт има 25 валидни - токена, следващата заявка за удостоверяване е успешна, но тихо обезсилва най-стария оставащ токен без видимо за потребителя предупреждение.

Ако трябва да упълномощите множество програми, машини или устройства, едно решение е да ограничите броя на клиентите, които упълномощавате за потребителски акаунт, до 15 или 20. Ако сте администратор на Google Apps, можете да създадете допълнителни администраторски потребители и да ги използвате да упълномощи някои от клиентите.

Така че, докато приложението ви не се инсталира повече от 15 пъти от един и същ потребител, не би трябвало да имате проблем. Ако това е проблем, можете да им предложите да използват различно / специално име за вход за вашето приложение.

person DaImTo    schedule 09.04.2014
comment
Благодаря. Но те говорят ли за достъп или за опресняване на токени? Също така не разбирам тези ограничения от 25 токена. Да речем, че потребителят [email protected] упълномощава моето приложение и след това оторизира още 25 приложения. Ще бъде ли анулиран маркерът за опресняване, даден на моето приложение (най-старото)? - person Martin Dimitrov; 09.04.2014
comment
Това е токенът за опресняване, за който говорят. Не забравяйте, че маркерът за достъп е валиден само за 1 час. Използвате токена за обновяване, за да получите нов. Можете да продължите да получавате нови токени за достъп толкова често, колкото желаете, като използвате токена за обновяване. (между другото прав си. Токенът за предоставяне е малко объркващ, ще изпратя на Google бележка за това) - person DaImTo; 09.04.2014
comment
Ако потребител [email protected] упълномощи ВАШЕТО ПРИЛОЖЕНИЕ 15-20 пъти, ПЪРВОТО означение за опресняване, което е имал с приложението ви, вече няма да работи. Това е вашето приложение, а не нечие приложение. - person DaImTo; 09.04.2014
comment
Това е първото ограничение one limit per client/user combination. Но вижте какво казва вторият: and another per use across all clients?!?! Как да прочета това? - person Martin Dimitrov; 09.04.2014
comment
Добър въпрос! Нямам представа какво имат предвид с това твърдение. Но знам кого да питам. Ще се свържа с вас за това. - person DaImTo; 09.04.2014
comment
Ето едно предположение, което тествам, можете да създадете повече от един идентификатор на клиент за вашето приложение. Мисля, че се отнасят до други идентификатори на клиенти, които може да сте създали. Така че, ако имате идентификационен номер на клиент за вашето приложение за уеб и друг за мобилно устройство, те все още се броят за един и същ клиент и двата се броят в един и същи максимум 15 - 20. Създаване на мини приложение за тестване - person DaImTo; 09.04.2014
comment
Направих тест на PHP скрипт. Моля, вижте резултатите в актуализирания въпрос. Благодаря. - person Martin Dimitrov; 11.04.2014
comment
Изпратих въпрос до Google с надеждата, че някой може да изясни какво има предвид с това изявление. Все още не съм чул нищо обратно. Ако го направя, ще ви уведомя - person DaImTo; 11.04.2014