Проблема с доступом в аккаунт на Покете

Странный костыль с заменой библиотеки. По мне так, перенос всего в память — это просто перекладывание проблемы из одного кармана в другой, потому что при любом рефреше страницы всё равно придётся заново авторизовываться. Неужели на Покете настолько криво реализован механизм обновления, что приходится менять весь клиентский стек? Я пробовал просто прописать жесткие заголовки в запросах, чтобы обходить этот глюк с refresh-токеном, но в итоге всё равно вылетало по тайм-ауту. Кажется, проблема глубже, чем просто место хранения данных. Скорее всего, сервер просто сбрасывает сессию по какому-то своему внутреннему триггеру, и никакая «чистая» версия библиотеки тут не поможет, если бэкенд так работает.

Насчёт того «костыля» с хранением токена в памяти – в моём случае он тоже не спасал от полной потери сессии после простого обновления окна. Я пробовал по‑другому: вместо того, чтобы полностью полагаться на клиентскую библиотеку, вынес отдельный слой, который кэширует refresh‑токен в IndexedDB и автоматически подсовывает его в запросы, даже если страница перезагрузилась. При этом основной скрипт не «перепрыгивает» в состояние незалогиненного, а сразу восстанавливает auth‑заголовок, пока сервер не откажет. Выглядит чуть громоздко, но в отличие от чисто «в памяти» решения, токен живёт между сессиями, а не исчезает при каждом reload. Да, это требует небольших доработок: обработка ошибок 401, проверка срока жизни токена и, при необходимости, запрос нового. Тем не менее, такой подход убирает постоянные переавторизации, которые в текущей реализации Покета, судя по всему, считаются нормой, а не «кривой» ошибкой. Если у кого‑то уже есть готовый патч или небольшая библиотека‑обёртка, скиньте – сэкономим время, а иначе придётся продолжать «ходить» по этим костылям каждый раз, когда браузер решит очистить память.

С IndexedDB возиться долго, но это реально единственный способ не вылетать из сессии при каждом рефреше, если библиотека тупит. Я пробовал вариант с LocalStorage, но там вопросы к безопасности всплывают сразу, особенно когда речь о токенах. AlphaStorm, а как у тебя с автоматическим обновлением реализовано? Просто если сессия всё равно отваливается по таймауту, то никакой кэш не поможет, придётся всё равно заново логиниться. По мне так, проблема в самой логике работы Покета с сессиями, а мы тут пытаемся костылями заклеить дыру в фундаменте.

С IndexedDB реально много мороки, но безопасность важнее. Я вообще считаю, что если библиотека так тупит с сессиями на Покете, то проще один раз нормально настроить рефреш-токены в httpOnly куках, чем городить огород с локальным хранилищем. А автообновление обычно ломается из-за кривых таймеров.

ну ты загнул насчёт того, что httpOnly куки — это всегда проще. я на Покете полгода бадался с доступом в аккаунт, и когда библиотека тупит с сессиями, куки тоже не панацея: если прокси или сам хостинг глючит, рефреш-токен просто не долетает и выкидывает на логин. у меня автообновление ломалось не из-за кривых таймеров, а потому что на стороне сервера Покета иногда отвечает 503 и фронт по таймауту сбрасывает сессию. IndexedDB морока, но хоть локально живёт, а с куками при жёстком рефреше окна вообще пусто. короче, безопасность важна, но не факт что один раз настроишь и забудешь — у меня после переезда на другой домен куки вообще перестали ставиться из-за SameSite, и опять лезть в код пришлось. лучше уж нормальный обработчик ошибок рефреша сделать, чем верить что браузер всё удержит.

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

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

Сетевой таймаут до 401 — это уже не про логику приложения, а про транспорт. Если коннект рвется на уровне сокета до того, как придет ответ с заголовками, никакой интерсептор в axios/fetch не сработает, просто потому что коллбэк не вызовется. Лечил такое на Покете только через кастомный адаптер с ретраями на уровне http-агента (keepalive + timeout на фазу коннекта отдельно от респонса) и обязательной идемпотентностью рефреша токена, иначе получишь гонку за новый аксесс при каждом обрыве.