Добавить OAuth как у Google в локальный AI-шлюз? «Всего один вечер», — подумал разработчик и…

Бывает, смотришь на задачу и думаешь: «Да тут на час работы, максимум — вечер». А потом просыпаешься через три дня с красными глазами и понимаешь, что OAuth — это не фича, а стиль жизни.

Именно это случилось с автором, который решил добавить Google-style OAuth в свой локальный AI-шлюз CliGate. Казалось бы, что может пойти не так? Ну, OAuth же стандартный, бери и подключай. Но реальность, как обычно, подложила свинью: успешная аутентификация, обновление токенов, project ID и привязка чата — это четыре совершенно разные вселенные, которые существуют по своим законам.

Разработчик честно признаётся: он думал, что справится за один вечер, но в итоге потратил кучу времени на отладку каждого из этих компонентов по отдельности. Особенно его добил момент, когда токен обновился, но чат продолжил падать с ошибкой — потому что project ID передавался не туда. Знакомая боль, да? Как будто собираешь IKEA, а в коробке оказываются детали от двух разных столов.

Чему нас учит эта история?

1. OAuth — это не функция, а система. Успешный логин — это только начало. Токены живут своей жизнью, project ID требуют маппинга, а привязка к источнику чата — это вообще отдельный квест.
2. Не верьте оценкам «на один вечер». Если вы не делали это раньше, закладывайте минимум в два раза больше. А лучше в три.
3. Документируйте каждый шаг. Когда через месяц придётся вспоминать, почему вы передаёте project ID через заголовок, а не через тело запроса, вы скажете себе спасибо.

В итоге автор всё-таки запустил CliGate с OAuth, но процесс превратился в эпопею. Как говорится, «хорошо, что не в production».

Комментарий студии METABYTE: Мы тоже любим истории про «один вечер», которые растягиваются на неделю. Если хотите добавить аутентификацию в свой проект без ночных кошмаров — обращайтесь. У нас есть прививка от «OAuth-бессонницы».