Аутентификация, сгенерированная ИИ, ломается в продакшене — алгоритм отладки

Как выглядят ошибки входа, когда «работает локально"

Вход может выглядеть нормально в продакшене и при этом быть сломанным. Форма отправляется, вы получаете ответ «успешно», а затем оказываются снова на странице входа.

Типичные симптомы:

• Цикл редиректов между страницей входа и приложением
• Кажется, что вы «вошли» на одну страницу, а потом внезапно выходите
• После обновления появляется 401 или 403, хотя минутой раньше всё работало
• OAuth завершается, но приложение ведёт себя так, будто вы не вошли
• Работает в одном браузере или на одном устройстве, а на другом — нет

Причина обычно банальна: аутентификация зависит от мелких деталей окружения, которые отличаются между локалью и продакшеном. Локальная разработка чаще — один хост, без прокси, простые cookie и HTTP. В продакшене добавляются HTTPS, реальные домены, reverse proxies и иногда отдельный домен для API. Эти различия влияют на то, как сохраняются cookie, какие заголовки получает сервер и куда идут редиректы.

Типичный пример: локально вы входите, срабатывает cookie сессии и браузер его сохраняет. В продакшене сервер всё ещё отправляет cookie, но браузер отказывает в сохранении, потому что флаги cookie не соответствуют реальной конфигурации (часто SameSite и Secure). Бэкенд думает, что вы залогинены, но браузер никогда не шлёт этот cookie обратно. Со стороны это выглядит как случайные выходы или бесконечный редирект.

Не догадывайтесь и не переписывайте всю систему аутентификации. Найдите точный шаг, где поток перестаёт быть корректным:

• Отправил ли сервер cookie или токен?
• Сохранил ли его браузер?
• Был ли он включён в следующий запрос?
• Упёрся ли редирект в правильный домен?
• Принял ли API сессию или токен?

Большинство продакшен‑сбоев в аутентификации — это настройки и поведение cookie, а не форма входа.

Команды вроде FixMyMess часто сталкиваются с этим в проектах, сгенерированных ИИ: интерфейс выглядит завершённым, но правила продакшена для доменов, HTTPS и сессий не были учтены.

Прежде чем трогать код: соберите чистый repro

Самые быстрые победы приходят из чистого, воспроизводимого repro, а не из догадок. Если вы сможете вызвать баг по требованию, вы быстро подтвердите исправление.

Запишите точный сценарий, чтобы кто‑то другой мог воспроизвести без лишних вопросов. Укажите устройство (десктоп или телефон), название и версию браузера, точную страницу, с которой вы начали, и учётную запись. Если ошибка проявляется только в режиме инкогнито, по мобильному трафику или после долгого открытия вкладки — зафиксируйте это.

Также уточните, где именно возникает ошибка. Многие «баги входа» ломаются не на экране логина, а сразу после него:

• Вы отправляете форму и прыгаете обратно на страницу входа
• OAuth выглядит успешным, но callback не завершается
• Вы попадаете в приложение, но первый API‑вызов возвращает 401 и вас выкидывает
• Работает один раз, затем падает после обновления или через 10–30 минут

Определите успех в конкретных терминах. Выберите одну‑две проверки, которые будете делать всегда: например, существует сессионный cookie, сохранён токен, или endpoint «current user» возвращает 200. Без этого команды «чинят» только UI, пока сервер по‑прежнему считает пользователя анонимным.

Добавьте временные и идентификационные подсказки. Зафиксируйте одну‑две метки времени воспроизведения (с точностью до минуты). Если в логах бэкенда видны request ID, session ID или trace ID — запишите их. Эти хлебные крошки часто связывают симптом в браузере с конкретной серверной ошибкой.

Быстрый шаблон repro

Опишите это как мини‑тест‑кейс:

• Окружение: production, браузер + версия, устройство
• Шаги: пошаговый путь от состояния разлогинивания
• Ожидаемо: ваш выбранный сигнал успеха (cookie установлена, токен сохранён, «current user» возвращает 200)
• Фактически: что вы увидели (цикл редиректов, страница ошибки, внезапный выход)

Реалистичный пример

Распространённый сценарий: «работает локально, падает только на деплое». Вы входите, видите короткий редирект и снова оказываетесь на странице входа.

Ваша проверка успеха может звучать так: «После входа запрос current‑user возвращает 200 и сессионный cookie присутствует». Если вы воспроизводите проблему в продакшене и этот запрос возвращает 401, вы уже сузили область поиска. Это не проверка пароля — это проблема с сохранением сессии, настройками cookie, обработкой callback или несоответствием proxy/домена.

Если вы наследуете запутанную кодовую базу, сгенерированную ИИ, такое чистое repro помогает сервисам вроде FixMyMess быстрее диагностировать, на каком шаге ломается поток: логин, callback, обновление или первый авторизованный API‑вызов.

Шаг 1: Проследите поток входа в браузере

Самый быстрый способ перестать гадать — увидеть, что реально отправляет и получает браузер. Большинство багов аутентификации хорошо видно на вкладке Network.

Откройте инкогнито, чтобы начать с нулём cookie и кеша. Затем откройте DevTools и держите панель Network видимой во время входа.

На что смотреть в Network

Найдите запрос, который отправляет учётные данные (часто endpoint login или session). Проверьте статус, но не останавливайтесь на «200». Ответ может быть успешным и при этом не устанавливать сессию или не возвращать пригодный токен.

Далее следуйте по цепочке запросов. Если в потоке есть редиректы (часто с OAuth), кликайте по каждому redirect‑ответу и смотрите заголовок Location. Много продакшен‑сбоев сводится к редиректу на неправильный домен, путь или на HTTP вместо HTTPS.

Короткий план для проверки потока:

• Найдите первый auth‑запрос и запишите код ответа.
• Для каждого редиректа подтвердите, что Location указывает туда, куда вы ожидаете.
• Просмотрите заголовки ответа на предмет Set‑Cookie.
• Следите за предупреждениями DevTools о заблокированных cookie.
• Подтвердите, что следующий API‑вызов включает заголовок Cookie или Authorization.

Подтвердите, что браузер принял сессию

Если вы видите Set‑Cookie в ответе, браузер всё ещё может его отклонить. Chrome часто показывает причину в деталях cookie или во вкладке Issues (SameSite, Secure, домен или путь — частые причины).

Наконец, проверьте первый авторизованный API‑вызов после «успешного» входа, например current‑user или profile. Посмотрите заголовки запроса. Если нет Cookie и нет Authorization, значит браузер не несёт сессию дальше. Это хорошее сужение: проблема не в «сервер забыл меня», а в том, что клиент не отправил доказательство входа.

Шаблон, который часто видит FixMyMess: всё работает в локальной разработке, но в продакшене OAuth callback завершается, а UI по‑прежнему показывает «вышли». На вкладке Network обычно видно, что cookie был установлен для локального хоста или заблокирован, потому что не был выставлен Secure на HTTPS‑сайте.

Шаг 2: Исправьте флаги cookie, которые ломают сессии

Cookie — частая причина ошибок «работает локально». Локальная среда снисходительна. Продакшен — нет.

Начните с проверки cookie сразу после успешного ответа на вход. Ищите сессионный cookie (или cookie refresh‑токена) и смотрите, сохранён ли он и отправляется ли затем на следующий запрос.

Флаги, которые решают судьбу cookie

Domain и Path определяют, куда cookie будет отправляться. Если фронтенд и API живут на разных хостах, cookie с узкой областью может никогда не быть отправлена туда, где вы ожидаете. Path тоже может подвести: cookie, установленная для пути авторизации, не будет отправлена к другим API‑роутам.

SameSite — главный параметр для OAuth и кросс‑сайтовых редиректов. Если поток уводит пользователя с вашего сайта и обратно, настройки SameSite могут сделать cookie недоступной между прыжками. Во многих OAuth‑случаях нужен SameSite=None, и тут есть жёсткое правило: такой cookie должен также иметь Secure.

Secure заставляет браузер отправлять cookie только по HTTPS. Это правильно для продакшена, но может ломать стенды или окружения, где ещё используется HTTP.

HttpOnly запрещает доступ JavaScript к cookie. Это обычно хорошо. Обычная ошибка в ИИ‑сгенерированном фронтенде — попытка читать сессионный cookie через JavaScript и считать, что вход не удался, если чтение невозможно.

Прежде чем менять код, проверьте эти распространённые подводные камни:

• Домен cookie совпадает с реальным production‑хостом (нет оставшихся локальных значений)
• Путь cookie достаточно широкий (обычно /)
• SameSite соответствует вашему потоку (особенно для OAuth)
• Secure включён в HTTPS‑окружениях
• Нет дубликатов cookie с одинаковым именем, но разными domain/path

Быстрый пример: основатель деплоит приложение за обратным прокси, OAuth «успешен», но приложение возвращается в состояние вышедшего. DevTools показывает два cookie с одним и тем же именем с разной областью. Браузер отправляет «не тот», и сервер его отвергает. Это выглядит как «рандомная аутентификация», пока не посмотришь область cookie.

Шаг 3: Проверьте HTTPS, домены и reverse proxy

Если работает локально, но ломается в продакшене, часто виновато не ваше auth‑логика, а как приложение размещено: HTTPS, публичный домен и прокси.

Убедитесь, что приложение знает реальную схему и хост

Многие продакшен‑развёртывания ставят приложение за load balancer или reverse proxy. Браузер говорит с прокси по HTTPS, а ваше приложение может видеть входящий запрос как HTTP, если не доверяет forwarded headers.

Когда это происходит, типичные симптомы: cookie устанавливаются без Secure, редиректы ведут на HTTP, и OAuth‑потоки ломаются, потому что приложение строит неправильный callback URL.

Быстрые проверки:

• В логах сервера выведите протокол и хост, которые приложение считает пришедшими.
• Убедитесь, что прокси отправляет forwarded headers (protocol и host обычно).
• Настройте приложение доверять прокси, чтобы оно безопасно использовало эти заголовки.

Устраните циклы редиректа и «не туда» редиректы

Классическая продакшен‑ошибка: вы входите, на мгновение попадаете в приложение, а затем снова и снова возвращаетесь на страницу входа. Часто логин прошёл, но цепочка редиректов переключается между HTTP и HTTPS или между двумя хостами.

Проверьте Network на точные цели редиректов. Ищите паттерны вроде:

• HTTP → HTTPS → HTTP циклы
• Редиректы на staging или старый домен
• Редиректы на локальный порт, которого нет в продакшене

Также подтвердите, что все URL, связанные с auth, используют публичный домен. OAuth‑провайдеры строги: если в настройках зарегистрирован один callback, а приложение отправляет пользователей в другое место, это не сработает.

Субдомены, область cookie и блокировки браузера

Если вы используете несколько субдоменов (например, один для приложения и один для API), решите, должны ли cookie быть общими или изолированными. Для общих cookie часто нужен scope на родитель‑домен; для изолированных — избегайте этого.

Функции приватности браузеров тоже важны. Если вход опирается на cookie в третьей стороне (встраиваемые флоу, кросс‑сайтовые редиректы), некоторые браузеры будут их блокировать, если SameSite и Secure не настроены правильно.

Если нужен второй взгляд на mismatch прокси и доменов, FixMyMess часто находит конкретный редирект или заголовок, который ломает поток, во время бесплатного аудита кода.

Шаг 4: Отладка OAuth callback и редиректов

Сбои OAuth выглядят запутанно: браузер прыгает между сайтами, а ошибка может появиться на странице провайдера, на вашем callback‑роуте или вообще нигде.

Определите, где всё ломается

Воспроизведите вход и обратите внимание, куда вы попадаете:

• Если вы оказываетесь на странице ошибки провайдера — провайдер отклоняет запрос (часто несоответствие redirect URI).
• Если вы возвращаетесь на сайт и видите ошибку приложения — ваш callback‑обработчик или обмен кода на токены падает.
• Если вы возвращаетесь «успешно», но видите себя разлогиненным, callback мог завершиться, но сессия не сохранилась.

Крупные проверки:

• Сравните настроенный redirect URI и фактический callback URL посимвольно (схема, домен, путь, слэш).
• Убедитесь, что для этого деплоя используются правильные переменные окружения (client ID, client secret, issuer и базовый URL приложения).
• Проверьте, что state (и nonce для OIDC) генерируется, сохраняется и валидируется после редиректа.
• Убедитесь, что callback попадает в ваш бэкенд и в запросе есть authorization code.
• Проверьте, что обмен кода возвращает токены и что ошибки не подавляются молча.

Частые шаблоны несоответствий

Несоответствия redirect URI редко очевидны. Типичные ошибки: HTTP vs HTTPS, другой субдомен, разные пути callback или слэш в конце в одном месте и без в другом.

Ошибки со state и nonce тоже часты в ИИ‑сгенерированном коде. Если state хранится в памяти, serverless‑развёртывания или несколько инстансов могут терять его между редиректами. Если state хранится в cookie, такая cookie может не пережить кросс‑сайт‑прыжок.

Реалистичный пример: Google login работает локально, но в продакшене возвращает «Invalid state». Корень проблемы часто в том, что базовый URL приложения всё ещё указывает на локальную разработку, поэтому state‑cookie записывается для неправильного хоста и не приходит обратно при callback.

Если нужен взгляд со стороны, FixMyMess обычно начинает с картирования точного redirect URI, хранения state и ответа на обмен токена, чтобы быстро увидеть место сбоя.

Шаг 5: Проверка JWT и обновления токенов

Если вход «кажется» успешным, но пользователей выкидывает после обновления страницы, в новой вкладке или через 10–30 минут, рассматривайте это как проблему с токенами до доказательства обратного. Небольшие различия во времени, ключах и правилах валидации могут сделать токен, который выглядит корректным локально, недействительным в продакшене.

Начните с того, что думает сервер о токене

Декодируйте токен и проверьте expiry (exp). Сравните его с текущим временем сервера. Несколько минут сдвига времени (clock skew) могут сделать только что выданный токен просроченным и вызвать 401.

Далее подтвердите настройку подписи и валидации:

• Алгоритм: сервер и клиент должны соглашаться по алгоритму подписи.
• Секрет или ключи: убедитесь, что на продакшене используется тот самый секрет или публичный ключ, который сервер на самом деле применяет.
• Правила валидации: проверьте issuer и audience. Они часто отличаются между локалью и продакшеном, особенно если в проекте копировали пример из ИИ‑подсказки.

Типичный случай «работает локально»: локальный код пропускает проверки issuer/audience для удобства, а продакшен‑middleware требует их. Токен валиден, но сервер отвергает его из‑за неправильной аудитории.

Проверьте, что обновление токенов работает при реальном поведении пользователя

Обновление токенов должно работать после перезагрузки или в новой вкладке. Протестируйте реалистичную последовательность: войдите, закройте вкладку, откройте сайт заново и сделайте API‑вызов. Если приложение хранит access token только в памяти, он исчезнет при перезагрузке и пользователь будет выглядеть разлогиненным.

Будьте осторожны с местом хранения токенов. Хранилище, которое переживает перезагрузку, удобно, но повышает риск при XSS. Cookies могут быть безопаснее при правильных настройках, но cookie с токеном также могут теряться из‑за флагов или области действия.

В унаследованном ИИ‑сгенерированном коде часто встречается наполовину реализованный поток обновления: refresh‑токен выдаётся, но не используется, или клиент никогда не сохраняет обновлённый токен. Endpoint входа выглядит нормально, но путь «после обновления» не был протестирован.

Быстрая проверка здравого смысла: логируйте причину отказа валидации токена на сервере (expired vs signature vs issuer/audience). Без этого вы будете гадать.

Проверки на сервере: CORS, CSRF и хранение сессий

Подсказки из браузера — только половина истории. Сервер может тихо отвергать запросы или хранить сессии там, где приложение не может их надежно прочитать.

CORS: разрешите реальный origin (и credentials)

Проблемы CORS часто выглядят так: «вход прошёл, а следующий запрос анонимен». В продакшене фронтенд и API обычно на разных origin.

Убедитесь, что API явно разрешает production origin (не звёздочку), и что он настроен на работу с credentials, если вы используете cookie. Если фронтенд отправляет запросы с включёнными credentials, а API не возвращает соответствующие CORS‑заголовки, браузер может игнорировать ответ или не принимать cookie.

Короткий серверный чеклист:

• Разрешить точный production origin (схема + домен)
• Возвращать разрешение для credentials при использовании cookie
• Обрабатывать preflight (OPTIONS) и возвращать ожидаемые заголовки
• Избегать нескольких конфликтующих CORS middleware
• Подтвердить, что разрешённые заголовки включают те, которые вы реально отправляете (например Authorization)

CSRF: POST работает локально, но падает в продакшене

Если вход использует POST (или у вас есть logout, refresh или обновления профиля), CSRF‑правила могут ломаться только в продакшене. Две частые причины: отсутствующие CSRF‑токены и более строгие правила для cookie.

Для cookie‑базированных сессий строгий SameSite может не позволить браузеру отправить сессионный cookie при кросс‑сайтовом POST. Сервер тогда отвергает запрос как лишённый CSRF‑токена или с неверным токеном.

Чтобы быстро отлаживать, логируйте для падающего запроса: origin, полученные cookie, CSRF‑токен/заголовок и причину отказа фреймворка.

Хранение сессий, балансировка нагрузки и секреты

Классическая продакшен‑ошибка: вы входите, получаете сессию, а затем все следующие запросы воспринимаются как новые. Частая причина — сессии не шарятся между инстансами.

Если у вас несколько процессов сервера (или хост авто‑масштабирует), вам нужны либо sticky sessions, либо общий стор сессий. Также проверьте имя cookie сессии и префиксы ключей — они должны быть одинаковы на всех инстансах.

Перепроверьте переменные окружения. Отсутствие секрета аутентификации, ключа подписи или ключа шифрования сессий может вызвать «рандомные» выходы после деплоя, потому что приложение падает на значение по умолчанию. Если это значение меняется при рестартах, старые сессии станут нечитаемыми.

Если вы унаследовали ИИ‑сгенерированное приложение и поведение аутентификации отличается между окружениями, FixMyMess может с помощью бесплатного аудита кода точно указать на CORS, CSRF, стор сессий и проблемы с секретами до того, как вы начнёте переписывать приложение.

Распространённые ловушки в ИИ‑сгенерированном коде для auth

Код, сгенерированный ИИ, часто работает в локальной разработке, потому что там всё просто: один домен, один порт, нет прокси и обычно HTTP. Продакшен добавляет HTTPS, реальные домены и прокси. Малые допущения превращаются в большие ошибки, и браузер выдаёт туманный цикл редиректов.

Один распространённый паттерн — смешение стилей аутентификации без чётких правил. Например, приложение ставит сессионный cookie после входа, а API ожидает bearer‑токен. Локально вы можете случайно отправлять оба варианта и «всё работает». В продакшене один путь проверяет cookie, другой — токен, и вы оказываетесь частично залогинены.

Ловушки, которые повторяются

Обратите внимание на следующие признаки при ревью кода и конфигурации:

• Несоответствие окружений: локальные допущения про HTTP, домены и порты протекают в продакшен
• Две истины: одновременно существуют session cookie и JWT без ясного правила, что и где используется
• Захардкоженные URL: значения redirect/callback или базовые URL вбиты в код или собираются по‑разному
• Повороты секретов: redeploy меняет ключи подписи или секреты сессий, что выкидывает пользователей или ломает refresh
• Ошибки подавляются: catch возвращает «ok» или редирект на страницу входа, скрывая реальный 401/403 или ошибку с токеном

Реалистичный пример: ИИ‑сгенерированное приложение нормально входит локально. В продакшене пользователи отправляют форму, но отскакивают обратно на страницу входа. Причина — три маленькие проблемы вместе: cookie не имеет Secure, OAuth callback всё ещё использует локальные настройки, а ошибки токенов перехватываются и превращаются в редиректы. Браузер видит только редиректы и думает, что «auth сломалась», хотя на самом деле cookie была отброшена.

Если вы унаследовали проект (Lovable, Bolt, v0, Cursor, Replit) и видите такие паттерны, FixMyMess обычно начинает с выбора единого источника правды для аутентификации, затем уплотняет секреты и конфигурацию окружения, чтобы входы переживали реальный трафик и деплои.

Короткий чеклист, один реальный пример и дальнейшие шаги

Вы можете сэкономить часы, проверяя базовые вещи в правильном порядке. Большинство ошибок «работает локально» не мистичны. Как правило, это cookie, которые не сохраняются, редиректы идут не туда, или приложение не отправляет креденшлы в первом же API‑вызове.

Быстрый чеклист на 5–10 минут:

• После входа видите ли вы заголовок Set‑Cookie (или ответ с токеном) во вкладке Network?
• Действительно ли браузер сохраняет cookie с ожидаемым доменом, путём и expiry, или он отклонён?
• В следующем запросе отправляется ли cookie обратно (или есть заголовок Authorization) при первом авторизованном API‑вызове?
• Если вы используете OAuth, точно ли зарегистрированный callback URL у провайдера совпадает с тем, что использует ваше production‑приложение?
• Во время обмена кода сервер возвращает 200, или вы видите тихий 400/401 из‑за плохого секрета, неправильного redirect или проблемы с прокси?

Реальный сценарий: OAuth работает локально, но падает на продакшен‑домене. Локально всё завершается. В продакшене провайдер редиректит обратно, но приложение не становится «вошедшим». На вкладке Network видно: callback попадает на сервер, сервер пытается установить сессионный cookie, но cookie блокируется из‑за отсутствия Secure на HTTPS или потому что SameSite слишком строг для кросс‑сайтового редиректа. UI загружается, сразу вызывает current‑user, этот запрос идёт без cookie, сервер отдаёт 401, и приложение возвращает на страницу входа.

Если поток всё ещё неясен, предполагайте, что код запутан, а не вы. ИИ‑сгенерированный код часто смешивает обязанности клиента и сервера, дублирует логику сессий или прячет критичную конфигурацию в разных местах. Фокусированный аудит обычно быстрее, чем метод проб и ошибок.

FixMyMess (fixmymess.ai) может диагностировать и починить ИИ‑сгенерированные auth‑флоу, включая cookie, JWT‑сессии, OAuth callback и готовность к деплою. Если вы хотите получить чёткий список того, что сломано, прежде чем вносить изменения, мы предлагаем бесплатный аудит кода; многие правки делаются в течение 48–72 часов с проверкой человеком.