Какие проблемы возникают при реализации логики авторизации в компоненте страницы

Что проверяют

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

Как отвечать

Проблемы, когда каждая страница сама проверяет пользователя в useEffect или onMounted:

• мигание защищённого контента: первый рендер проходит до проверки, пользователь на мгновение видит страницу, или она успевает запросить данные, и только потом случается редирект;
• дублирование: одна проверка в двадцати компонентах. Новую страницу добавили без неё, и она открыта всем;
• гонка с загрузкой сессии: пока токен читается или обновляется, страница считает пользователя гостем и выкидывает на логин, хотя сессия жива. Отсюда же циклы редиректов;
• потерянный адрес возврата: после входа человек попадает на главную, а не на ту ссылку, по которой пришёл;
• смешение ответственности: компонент знает про токены, роли и редиректы, его трудно тестировать.

Как устроить:

• на уровне маршрутов: layout-маршрут с проверкой и <Outlet /> или loader в React Router, beforeEach во Vue Router, CanActivateFn в Angular. В Next.js проверка идёт на сервере, в layout или в proxy.ts (так в Next.js 16 называется бывший middleware.ts);
• единый источник сессии: провайдер или стор с тремя состояниями «загружается», «гость», «авторизован», чтобы не путать неизвестное с отсутствующим;
• права как данные: хелпер вроде can(user, "edit", post) вместо сравнения ролей в разметке.

И главное: API само проверяет права на каждом запросе и отвечает 401 или 403. Клиентская проверка решает только, что показать.

Где спотыкаются

Считают скрытую кнопку или редирект защитой. API можно вызвать напрямую, и без проверки на сервере данные доступны всем.

Кладут токен в localStorage и не думают про XSS: любой внедрённый скрипт его прочитает. Надёжнее cookie с HttpOnly, Secure и SameSite, но тогда нужна защита от CSRF.

Полагаются только на middleware в Next.js. Весной 2025 года там нашли обход проверки через служебный заголовок, поэтому доступ проверяют и там, где читаются данные.