OAuth 2.0 в amoCRM REST API на PHP простым языком: получение, хранение и обновление токенов

[prishelec]

Сейчас можно создавать долгодействующий токен. Что очень удобно..

[IvanDB]

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

[prishelec]

Сначала был вечный токен. Потом временный через OAuth 2.0.

У меня был алгоритм. Если получаем ошибку 401 то обновляем токен и заново используем метод который использовали. Но бывает проблема на сервере и все токен не обновиться. В теории да, можно предусмотреть дополнительную обработку и т.д.

По поводу ваших клиентов. Ну напишите в мануале где брать токен без всяких OAuth 2.0. Меньше «головной боли» будет.

 

[IvanDB]

Если клиент будет себе ставить приложение с маркета Амо, то врят ли он будет заморачиватсья с токенами, им надо нажать кнопки и что бы все работало. Хотя может и будут копировать токен, надо будет смотреть, потому что если у готового приложения OAuth 2.0 будет отлетать из за того что токен не обновить, то проще и правда сделать инструкцию откуда скопировать долгосрочный и куда вставить. Спасибо за идеи.

[gotham_engineer]

Разбор полезный у Вас!) Однако гонять пустой curl-запрос в амо ради проверки токена перед каждым действием пожалуй жесткий оверхед. Если пойдет нормальный поток лидов, интеграция быстро упрется в лимиты самого API, да и скорость работы системы просядет. проще кэшировать это дело. Токены закидываются в Redis с TTL плюс минус чуть меньше суток. База проверяет всё локально в памяти за миллисекунды, а запрос на обновление улетает только тогда, когда время жизни старого токена реально на исходе.

Вы не замеряли, насколько сокращается время отклика всей интеграции, если убрать этот лишний сетевой запрос из цепочки?

[IvanDB]

Я понимаю что curl-ом гонять постоянно запрос токена это прокатит только на малых объемах, если там пойдет большой поток то все забуксует. У меня пока что клиенты бывают с малыми потоками данных по API, поэтому для них такого кода более чем хватит, если там в сутки 3-5-7 запросов ничего не нагрузится.

Если там конечно 300 запросов в сутки будет (был один потенциальный клиент с hh в Амо с таким объемом) то тут проблемы могут начаться, но я до такой разработки пока не дошел и буду решать по мере поступления.

Я слышал про значение expires_at передающееся с токеном, т.е. хранить в БД время жизни токена, делать проверку по IF и запрашивать у БД данные жив или нет, а по не API проверять каждый раз - точно будет быстрее у своей БД запросить, чем по API гонять каждый раз.

Redis с TTL в оперативку - мне кажется это имеет место быть если там 1000+ запросов в сутки может быть и параллельные процессы, т.е. потоковая работа идет.

Время отклика пока не замерял, в рамках тех задач что были это не особо критично.

[gotham_engineer]

Спасибо за развернутый бэкенд). Логика понятна: про expires_at в БД — абсолютно рабочая схема для большинства API впринципе. Но блин, конкретно с amoCRM есть одна жесткая подводная засада, из-за которой Redis с TTL либо аналог в памяти приходится городить с самого первого запроса. Просто при каждом обновлении access-токена старый refresh-токен моментом сгорает и выдается пара новых. Если на систему прилетает два параллельных хука ( типа юзер отправил два быстрых сообщения подряд) = два curl-запроса на обновление токена улетают одновременно. Что на выхлопе получается гонка данных: первый запрос обновит ключи, а второй падет из-за того, что его refresh-токен уже аннулирован. А итог - интеграция намертво ложится, пока клиент руками заново не авторизуется.Поэтому кэш в оперативной памяти с блокировкой повторных запросов на обновление - это в amoCRM становится вынужденная мера безопасности, и пофиг что в сутки идет всего 10 запросов. Спасибо ещё раз за интересную и продуктивную дискуссию))

[IvanDB]

По поводу параллельности и одновременности запросов это да, я про это думал, тут может быть сбой. expires_at в БД мне кажется это сможет решить, потому что если токен не истек, то он два раза одновременно использует его и по идее проблем быть не должно. Но если токен истек, то тут да, один запрос может потеряться в момент обновления. Шанс малый но есть. Redis с TTL должен исключить полностью.

Вам спасибо за диалог и обмен опытом, всегда полезно узнать опыт других.

[gotham_engineer]

Ваша правда: пока токен жив, параллельные запросы работают без проблем. Затык именно в момент ротации раз в сутки.

Могу по себе сказать: Redis с TTL пожалуй лишь один из вариантов, и без атомарной блокировки (вроде SET NX или flock) от гонки в момент удаления ключа он не спасет по большей части. Пачка параллельных хуков все равно может синхронно ломануться в API. Проблема специфическая как оказывается специфичная и даже скрытая = общался по этому вопросу с интегратором, у которого за плечами более 240 кейсов, и даже там этот момент со сгоранием долбанного refresh_token на нагруженных проектах вызывал ступор.

В любом случае, круто, что подняли эту тему. Было приятно подискутировать и обменяться опытом!) Ждем новых разборов по специфике работы с CRM))