2013-05-03 4 views
1

Я использую клиент PHP API Google (http://code.google.com/p/google-api-php-client/), чтобы сделать запросы OAuth - получить новый токен доступа.Предел скорости пользователя превышен для облачного хранилища Google OAuth2 API

Я кэшировал токен обновления и использовал его для создания нового токена доступа. Я просмотрел документацию (https://developers.google.com/accounts/docs/OAuth2,), и он говорит только о ограничениях на токена обновления (один лимит на комбинацию между клиентом и пользователем и другой для каждого пользователя на всех клиентах), но ничего о ограничениях токена доступа (за исключением того факта, что токен доступа действителен только в течение часа).

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

Но когда я пытаюсь сделать это, я вижу эту ошибку:

Error No: 1 
Error on Line: 242 
Error Message: Uncaught exception 'apiAuthException' with message 'Error refreshing the OAuth2 token, message: 
<HTML> 
<HEAD> 
<TITLE>User Rate Limit Exceeded</TITLE> 
</HEAD> 
<BODY BGCOLOR="#FFFFFF" TEXT="#000000"> 
<H1>User Rate Limit Exceeded</H1> 
<H2>Error 403</H2> 
</BODY> 
</HTML> 

Это потому, что я порождая много (16 на данный момент) от доступа токенов?

Если нет, что тогда вызывает эту ошибку? Каков наилучший способ обойти эту ошибку?

Есть ли страница документации Google, которая документирует ограничения скорости пользователя?

ответ

6

Там нет ограничений на маркеры доступа, основанные на знак обновления. Однако существует ограничение на скорость , на которую можно запросить токены доступа. Вы можете запросить тысячи токенов доступа на основе одного токена обновления, где все они одновременно действительны, но если вы превысите несколько qps запросов одновременного доступа к токенам, вы превысите предел скорости.

Как уже упоминалось выше, один идентификатор access_token может быть повторно использован параллельно в нескольких запросах, если он действителен для всех этих запросов.

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

+0

спасибо, брено ... не могли бы вы расширить это? > ограничения на access_tokens не публикуются, поскольку они могут быть изменены –

+0

Мы работаем над расширением этих ограничений. И наоборот, мы можем быть вынуждены сократить их в исключительных случаях, скажем, DoS-атаку. Лучше не требовать жестких требований к емкости сервера в вашем клиенте, а создавать алгоритм, который может масштабироваться вверх или вниз автоматически. Экспоненциальная резервная копия дает вам это. – breno

+0

Спасибо, Брено. Существуют ли какие-либо планы по реализации этого (экспоненциального отсрочка) в библиотеке google-api-php-client? Он работает лучше, если 403 поймал метод refreshToken(), вместо того, чтобы пытаться поймать ошибку, вызванную методом refreshToken(). –

1

Существует ограничение на количество токенов доступа. Когда вы запрашиваете новый токен доступа с помощью токена обновления, он может перезаписать ранее назначенный токен доступа, даже если предел времени не превышен (да, есть максимальное количество токенов доступа, которые вы можете активировать за один раз).

Кроме того, существует ограничение на скорость, с которой вы можете использовать токен обновления, чтобы запросить новый токен доступа.

Лучшим способом для этого является создание центрального процесса управления ключами, который отвечает за получение нового токена доступа каждые x минут (если тайм-аут составляет час, например, 30 минут). Распараллеливаемые процессы затем запрашивают токен единого доступа из процесса управления центральным ключом.

По https://developers.google.com/accounts/docs/OAuth2:

Access tokens have a limited lifetime and, in some cases, an application needs access to a Google API beyond the lifetime of a single access token. When this is the case, your application can obtain what is called a refresh token. A refresh token allows your application to obtain new access tokens.

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

+0

Спасибо за ответ.Это где-то в Google? –

+0

Найдите слово «лимит» на этой странице: https://developers.google.com/accounts/docs/OAuth2 – rein

+1

Не могли бы вы отредактировать свой ответ, чтобы уточнить, что лимит на refresh_tokens, а не access_tokens, который вы получаете от них? Единственным пределом тока в access_tokens является _rate_, при котором они могут быть запрошены. – breno