Angular AuthGuard — это правильное решение?
Я хотел бы создать защиту маршрута для защиты маршрутов от неавторизованных пользователей.
Я использую jsonwebtoken для авторизации и на данный момент сохраняю его в localStorage.
Моя идея заключается в том, что когда пользователь хочет получить доступ к защищенному маршруту администратора, authguard отправляет токен для проверки на сервер nodeJS/Express, который после проверки возвращает true или 401 (независимо от того, является ли пользователь администратором) на стороне клиента.
служба авторизации:
isLoggedIn(){
let headers = new HttpHeaders().set('x-auth-token',localStorage.getItem('token') || '');
return this.http.post('http://localhost:3000/api/users/check-auth', {}, { headers: headers }).toPromise();
}
Сервис authGuard:
canActivate(){
return this.sign.isLoggedIn().then(res => {return res;}).catch(ex => {return ex});
}
Моя цель состояла бы в том, чтобы избежать ручной установки ключа маркера в локальном хранилище пользователем для просмотра защищенного маршрута, даже если он не сможет реализовать какой-либо запрос XHR.
Не могли бы вы проверить, хорошая это идея или плохая, и придумать лучшее решение с точки зрения безопасности? Большое спасибо!
На самом деле 400 указывает на то, что содержимое http-запроса недействительно. 401 действительно для несанкционированных запросов.
Спасибо, я исправлю ответ 401. :)
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Хорошей практикой было бы управление ролями (или разрешениями) на уровне модели на стороне сервера. Например, класс User может иметь свойство roles, например:
auth.service.ts
myUser.roles = ['ROLE_ADMIN']
Таким образом, когда ваш пользователь входит в систему, вы можете сохранить информацию в вашем auth.service.ts
// auth.service.ts
get isAdmin() {
return this.user.roles.includes('ROLE_ADMIN')
}
Обратите внимание, что обычно вы хотите хранить эту информацию в управлении состоянием вашего приложения, будь то простые rxjs, ngrx, ngxs...
Наконец, вы должны добавить AuthInterceptor, который будет перенаправлять вашего пользователя, если ваш API возвращает ошибку 401.
Разрешения определены в моделях мангуста и включены в файл jwt. Если я хорошо понимаю, было бы лучше хранить в службе на стороне клиента при аутентификации разрешение вошедшего в систему пользователя, верно?
да. Вам не нужно делать запрос к API каждый раз, когда вы хотите перейти в ограниченную область вашего приложения. Защищенная часть вашего приложения в любом случае будет на стороне сервера, и это возможно благодаря пакету jwt.
Я думаю, что это хорошая практика, за исключением ответа 401. Технически клиент не делал недопустимый запрос. Ответ 401 указывает, что содержание HTTP GET недействителен. Сервер должен выдать 200 в случае успеха и содержать флаг в теле, который клиент читает, чтобы узнать, разрешен ли пользователю. Ошибки 401 регистрируются в консоли и сетевых панелях браузера как неверные запросы.