API Google Календаря - ключ API больше не действует без причины (400) - PullRequest
0 голосов
/ 13 июля 2020

У меня есть приложение (php), которое работает с API годами. Однако через несколько недель после go он начал спорадически выдавать ошибку:

(400) API-ключ недействителен. Пожалуйста, передайте действительный ключ API.

В итоге ошибка была непрерывной и перестала отвечать.

Я связал ее с API Календаря Google - больше не авторизовано для чтения?

После нескольких дней бездействия приложение снова работало в течение нескольких дней, но образец повторялся снова:

Он выдает ошибку все чаще и чаще, пока не перестанет работать .

Отредактировано:

Приложение можно посмотреть по адресу:

http://intraneteina.unizar.es/intraneteina/index.php?r=calendarioGoo / index

При выборе любого варианта из в раскрывающемся списке приложение считывает информацию из календаря Google и отображает ее в формате html.

Оно работает годами и, не касаясь кода, теперь выдает описанный ключ ошибки API недействителен.

1 Ответ

0 голосов
/ 17 июля 2020

У меня была аналогичная проблема. В конце концов я нашел документацию, в которой говорилось, что для приложения разрешено не более 50 (или, возможно, 100) «активных» токенов авторизации, если вы не запускаете его через учетную запись службы. Обычно при достижении лимита Google просто сбрасывает авторизацию с конца поддерживаемого им «активного списка», и вы не подозреваете об этом. Это проблема, если вы полагаетесь на истечение срока действия вашего токена доступа и не генерируете токен refre sh, пока не решите, что вам это нужно - т.е. когда вы генерируете / refre sh свой токен доступа, вы записываете дату истечения срока действия. и только refre sh это, когда система сообщает вам, что срок действия вашего токена истек.

Поскольку Google, возможно, отключил этот токен (удалил его из активного списка) в фоновом режиме, и вы не знаете об этом, вы пытаетесь использовать этот токен, срок действия которого не истек - в результате обычно получается неинформативное сообщение об ошибке без указания того, что произошло. В нашем случае в краткосрочной перспективе настройка учетной записи службы была слишком сложной (реализация RSA256 для процесса авторизации), поэтому мы обошли эту проблему, просто проигнорировав записанную метку времени истечения срока действия и запрашивая токен refre sh каждый раз, когда мы звонили на API. Извините, я не могу связать вас с документацией, но я считаю, что нашел ее через ответ в другом сообщении SO.

...