Роман Александрович: Не соглашусь, авторизованный пользователь может и должен иметь переходить с урла на нужную страницу.
По вашей логике: Захожу на урл user/profile меня зачем то редиректит на /login (допустим), там почему-то выполняется проверка на токен и загрузка данных и оттуда меня неизвестно куда должно редиректнуть.
Авторизация - это авторизация, пользователь с токеном, туда доступа не должен даже иметь, так как подразумеватся, что он уже авторизован.
На данный момент решение вопроса только с помощью ssr вижу.
Благодарю за мысли.
Роман Александрович: Что будет видеть пользователь, если он на прямую из адресной строки перейдет на эту страницу? Тот же самый прелоадер, что был и до этого? Либо готовую страницу, которая потом измениться в себе большую часть данных?
Роман Александрович: нет такой вариант не подходит. В случае получения новых данных пользователя, у многих компонентов будет перерендер с новыми данными, это будет выглядить просто "вырви глаза".
На данный момент, меняется просто компонент со входа - на фио юзера.
В Вашем случае у меня будет вся страница себя так вести, потом что 70% данных пользователя изменяются.
Внимательней прочитайте описание вопроса.
В кратце: пользователь авторизован - жмет f5 - происходит чек на токен, загрузка данных с api, в этот момент на экране не должно быть не лоадеров, не смены компонентов с войти - на имя пользователя.
Это все хорошо и понятно. Но, у меня в сервисе имеется массив, в котором я храню данные, в виде промиса, полученные от сервера, и соответственно мне необходимо с ними работать (редактировать, удалять и т.д.).
При редактирование мне необходимо сообщить об этом серверу и сообщить сервису, в котором лежит этот массив и изменить в нем данный элемент.
Вот и проблема та в том, как мне изменить в сервисе данные элемент массива, если все данные в нем в виде промиса, не запрашивать же после каждого редактирования/удаления новый список данных.
Олег Драпеза: да не стоит делать refresh на клиенте. Краш запросов, на мой личный взгяд, это далеко не правильное решение. Советую прислушаться к моему решению проблемы с обновление токена на сервере через заголовки, это решает все проблемы, запросы работаю стабильно и нет не какие ошибок, а Вам на клиенте необходимо всего лишь перекладывать токена из заголовка, если его присылает Вам сервер. Единственное осталось решить, чтобы асинхронные запросы при обновление токена не создавали новый экземпляр.
Да, по такому типо я и сделал, но это решение подходит лишь при отправке одного запроса. Если уходит 2 и более запросов асинхронно, все они уходят со старым токеном и на сервере токен обновляется после первого запроса, следовательно все последующие запросы отваливаются, до следующего их запуска.
Что касается, данного вопроса, я перепробовал уже много способов и самый лучше из всех, это не отправлять никакие запросы на refresh, а получать в заголовке новый токен от сервера и перезаписывать на старый.
Но такая схема тоже имеет свои недочеты и поэтому все сделал по другому.
Как я решил проблему.
На сервер уходят запросы и если время токена истекло, в ответе, заголовком, сервер возвращает новый токен, который я перезаписываю, но старый токен, на сервере, живет еще минуту, поэтому все асинхронные запросы проходят успешно.
Единственная косяк всплыл, что сколько запросов ушло асинхронно, в момент окончания жизни токена, столько раз сервер и создал новый токен для пользователя.
Токен перенс в храние local storage, и реализовал на клиенте след способом:
jwtInterceptorProvider.tokenGetter = ['jwtHelper', '$http', 'AuthUser', 'API', '$state',
function(jwtHelper, $http, AuthUser, API, $state) {
var token = AuthUser.getToken();
if(token){
if (jwtHelper.isTokenExpired(token)) {
return $http({
url: API.url + 'login/refresh',
skipAuthorization: true,
method: 'GET',
headers : { Authorization : 'Bearer '+ token},
}).then(function(res) {
AuthUser.setToken(res.data.token);
return res.data.token;
});
} else {
return token;
};
};
}];
jwtInterceptorProvider.forceHeadersUpdate = true;
$httpProvider.interceptors.push('jwtInterceptor');
Но запрос на refresh уходит от каждого запроса за данными на сервер, допустим на странице ссылается два запроса и уходит два запроса на рефреш токена, и соответственно второй запрос выдает 500 ошибку. Не подскажите, как быть с этой проблемой?
так и пытаюсь реализовать все, но упераюсь в то, что написал всю логику проверок в одной функции сервиса, вызываю ее в ран конфиге, допустим service.Accessfunc, и на выходе я хочу иметь true или false, но промис отдает мне https://i.gyazo.com/fe2964fda17b6cb15df48a89fca5fc... и я не могу найти достоверной инфы, как в итоге мне получить истину.
asdz: С авторизацией все ок у меня. После отправки логина пароля, приходит токен и лежит в куках, и по нему все чекается адекватно. Дело в том что у меня есть 3 ЛК, юзер, админ и менеджер, и надо закрыть доступ каждому из них к другим кабинетам. Вот для этого у меня и проверяются роли, по которым дает доступ или не дает.
Ну все таки я думаю сделаю, запись роли в куки и ее буду чекать при каждом переходе с тем что дает сервер.
Просто хотелось бы спрятать все не нужные для глаз данные, чтобы их не могли трогать "гении".
Максим Нагаев: Ну согласитесь, не красиво будет, если пользователь попадет на открытую даже страницу без данных. При переходе на страницы, пользователю сразу должно быть отказано в доступе к ней, и визуально не какого эффекта для него не произойдет.
Хочется сделать не просто чтобы было, а чтобы работало как это должно работать.
Alex: От роли зависит, в какой ЛК человек попадет и на какие страницы он сможет обратиться.
В данном случае при релоаеде страницы, вьюхи не прогружаются, потом что роли в проверки нет и доступ ему отказан. Но если не релоадить то все ок, так как данные все на месте
Проверка идет в ран конфиге, если в условие запускаю функцию, чтобы закинуть в сервис данные с сервера, он происходит асинхронно и проверка на роли чекается с undefined, а только потом уже записываются данные, и как эту цепочку совместить в промисы не могу раскидать в голове.
И как я понял, цепочка с .then в ран конфиге нельзя юзать.
Алексей Ярков: Благодарю, попробую по Вашему примеру реализовать у себя в проекте. Но есть такой вопрос, допустим у меня в ЛК около 30 маршрутов и к каждому привязывать resolve и на каждый контроллер вешать условие, как то не очень практично. Как быть?
А за решение огромной спасибо!
По вашей логике: Захожу на урл user/profile меня зачем то редиректит на /login (допустим), там почему-то выполняется проверка на токен и загрузка данных и оттуда меня неизвестно куда должно редиректнуть.
Авторизация - это авторизация, пользователь с токеном, туда доступа не должен даже иметь, так как подразумеватся, что он уже авторизован.
На данный момент решение вопроса только с помощью ssr вижу.
Благодарю за мысли.