Грубо говоря, сначала идет проверка токена в localstorage, если его

нет - на страницу логина, если он есть - попытка запроса на сервер, а потом уже, в зависимости от ответа, решать, что рендерить - логин или дефолт лейаут?

ну если выбросить некоторые этапы, то да но в вашем случае не надо выбрасывать логические этапы, ща опишу подробнее и токен не надо хранить в local storage, но это другая тема

2. Запрос возвращает ответ о том, что «недостаточно прав», это может быть наши расценено как ошибка в сохранении токена или подделка токена или что угодно другое, важно то, что сервер не считает этого пользователя авторизованным, тогда мы например в хуках нашего HTTP клиента или еще где-то где можно отслеживать ошибка запросов препринимаем какую-то логику, например очищаем нашу информацию о залогиненности и редиректим на /login, а это опять уже описанный выше сценарий сценарий (как правильно прокинуть функцию роутера в хук http клиента сложный вопрос внедрения зависимостей, но не особо существенный в текущем контексте, на данном этапе разбора темы можно сделать как угодно, а затем вернуться к этой теме) * оговорка - хорошей практикой будет являться наличие «локальных middleware» и этап запроса данных будет выполняться тоже как «промежуточное ПО» без попытки рендеринга, в Nuxt для этого есть устаревший fetch у каждой страницы-компонента, но сейчас его предлагают заменить на «анонимные middleware», но то несколько другая тема опять же Сценарий, когда пользователь запрашивает /public думаю очевиден, там вообще можно не применять Auth Middleware, потому что он всегда резолвится Эта логика верна не только для Vue App, в том или ином виде она присутствует почти везде, лейтмотив всего этого - разделение зон ответственности

===Наши основные слои == router совершает переходы между страницами (изменяет url) «хуки», «navigation guards», чтобы к нему можно было присоединить другое ПО, промежуточное ПО, которое будет выполняться между переходами (отсюда и название) == router middleware «промежуточное» ПО, встраивается в router и вызывается как минимум перед каждым запросом это просто набор неких функций на входе у этих функций информация, как минимум такая -с какой страницы совершен переход -на какую страницу производится переход -функции управления роутером, в данном случае интересны next и redirect -мы сами сюда же можем добавить информацию о «контексте», например доступ в Vuex или каким-то другим глобально доступным компонентам нашей системы, неважно next - это переход к следующему middleware (промежуточному обработчику) (если есть) когда все next выполнены (зарезолвлены), то роутер понимает, что можно завершать переход и переходить к конечному этапу, когда управление передается следующему слою и router-view начинает что-то рендерить redirect - это перенаправление (кэп, да), означает, что текущий событийный цикл завершен, нас отправили на некую новую страницу и вся цепь событий должна пройти ==router-view решает какой компонент показать, принимает это решение на основе текущего состояния router ===Пример работы предположим у нас есть 3 страницы /login - доступен только неавторизованным /public - доступен всем /secret - доступен только авториованным Первый сценарий, неавторизованный юзер заходит на /login 1. Запрос обрабатывается роутером 2. Роутер вызывает свои middleware 3. Auth Middleware принимает на вход описанную выше информацию, нам интересно 4. то, что запрашивается /login 5. то, что этот роут доступен публично (как именно это настроить вариантов много, можно передавать некую мету информацию при насройке роутера) 6. то, что пользователь не авторизован 7. На основе этого он вызывает переданную функцию next(), «резолвится», разрешает дальнейший переход 8. Роутер успешно отрабатывает, router-view имеет возможность получить свой «активный» компонент для рендеринга Тут пользователь может отправить форму на апи сервер, получить в ответ какой-то токен и записать его в Vuex или еще куда-то, пока неважно. Важно то, что наше приложение сможет знать о том, что пользователь «авторизовался» Второй сценарий, авторизованный юзер заходит на /login 1. Запрос обрабатывается роутером 2. Роутер вызывает свои middleware 3. Auth Middleware принимает на вход описанную выше информацию, нам интересно 4. то, что запрашивается /login 5. то, что этот роут доступен публично 6. то, что пользователь авторизован 7. предыдущий пункт не дает этого промежуточному ПО разрешиться (зарезолвится), он не вызывает next, а делает что-то другой, например пользуется функцией redirect чтобы отправить куда-то пользователя, это может быть предыдущая страница или главная страница, неважно, пускай в нашем случае будет redirect на secret 8. redirect завершил текущий событийный цикл, далее начался новый «авторизованный пользователь запрашивает страницу /secret», можно его рассмотреть отдельно 1. Роутер успешно отрабатывает, router-view имеет возможность получить свой «активный» компонент для рендеринга Третий сценарий, авторизованный юзер заходит на /secret 1-2 такие же Auth Middleware теперь имеет другую информацию на входе 1. то, что запрашивается /secret 2. то, что этот роут не доступен публично 3. то, что пользователь авторизован 4. все сходится, вызывается next 5. router-view пытается отобразить страницу запрошенная страница пытается получить некие данные для отображения себя и тут может быть 2 варианта 1. Запрос возвращает данные и все хорошо, страница рендерится, данные показываются