Как бороться с тайм-аутом сеанса (или токеном с истекшим сроком действия), когда нет маршрутизации по ссылке в angular 4 - PullRequest
0 голосов
/ 06 сентября 2018

У меня есть один очень распространенный сценарий для токена с истекшим сроком действия, как показано ниже, Kindle помогает мне с этим справиться.

мой сеанс подачи заявки занимает 30 минут, теперь, скажем, я на одной странице больше 30 минут, затем нажимаю на любую другую ссылку на страницу. поэтому он будет перенаправлен на страницу входа. здесь, перенаправить через маршрутизацию, чтобы активная защита появилась на картинке и проверить, не истек ли токен, затем перенаправить на страницу входа. пока все выглядит хорошо. работает нормально.

однако, допустим, у меня есть ссылка обновления (которая обновляет запись таблицы с помощью вызова get get http) на той же странице, которая просто обновляет записи таблицы (это не обновление всей страницы). если я нахожусь на той же странице более 30 минут и нажимаю кнопку обновления, как проверить, что токен истек или нет. поскольку в этом сценарии обновления маршрутизация не используется, поэтому она не перейдет к активному контролю, чтобы проверить, истек ли токен.

Не могли бы вы подсказать мне, как бороться с этим вариантом использования.

Заранее спасибо !!!

Ответы [ 2 ]

0 голосов
/ 06 сентября 2018

enter image description here

В нашей среде для обеспечения наилучшего возможного UX пользователи не перенаправляются на страницу входа по истечении сеанса.

Вместо этого вся страница размыта, и отображается модальный режим, который требует ввода пароля и содержит кнопку отправки, как указано выше.

Основные преимущества этого подхода:

  1. Как избежать разочарования в связи с потерей несохраненной работы во время перенаправления.
  2. Более бесподобный опыт повторной аутентификации.

Аналогично некоторым из ответов, описанных здесь - https://ux.stackexchange.com/questions/7195/best-practices-for-warning-of-session-expiration

Как этого добиться в Angular?

  1. При успешном первом входе в систему напишите дату / время, когда сеанс будет истекает в localStorage, например new Date() + 30 minutes.
  2. Введите, например, authentication.service.ts на уровне приложения, что есть setInterval(() => checkSessionTimeout(), e.g every 1 minute) внутри своего конструктора. Такой подход гарантирует, что этот метод будет работать и на новых вкладках / окнах.
  3. Создайте метод checkSessionTimeout(), который выводит сколько минут оставшееся до времени ожидания сеанса и записать его в переменную в authentication.service.ts например sessionTimeoutIn: number;
  4. Создайте компонент, который будет содержать модал для повторной аутентификации как показано на изображении выше. Внедрить этот компонент на уровне приложения с <app-re-authenticate-modal *ngIf="authenticationService.sessionTimeoutIn <= 0"></app-re-authenticate-modal>
  5. Для эффекта размытия добавьте класс к своему телу / основному с помощью [class.blur]="authenticationService.sessionTimeoutIn <= 0"
  6. Для еще лучшего опыта создайте div, который выдвигает основной / тело, и входит в вид сверху, который содержит это, которое может управляться с <div *ngIf="authenticationService.sessionTimeoutIn > 0 && authenticationService.sessionTimeoutIn <= 2"></div>:

enter image description here

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

Надеюсь, это поможет.

0 голосов
/ 06 сентября 2018

Внутри вашего CanActivate охранника маршрута вы можете возвращать либо Promise<boolean>, либо Observable<boolean>, либо boolean.

Но внутри того же самого защитного файла вы также можете полагаться на сервис, который возвращает вам true или false в зависимости от того, истек ли токен или нет. И это, в свою очередь, то, что вы, возможно, возвращаете из своей гвардии.

Предположим, что AuthService проверяет, не истек ли токен аутентификации. А Служба данных получает данные для вас.

Теперь, прежде чем обновлять эти данные, вы можете снова проверить их, внедрив этот AuthService в свой DataService в качестве зависимости, а затем проверив, истек ли токен.

В качестве альтернативы , ваш API может проверить, был ли этот запрос аутентифицирован или нет. Для этого вам потребуется отправлять заголовок авторизации с каждым запросом. В таком случае вы можете использовать HttpInterceptor. Этот перехватчик будет перехватывать каждый исходящий запрос, чтобы проверить, присутствует ли на нем заголовок Authorization. Если он присутствует, только тогда он разрешит выполнение запроса. Если нет, вы можете сделать все необходимое, переместив пользователя обратно на страницу входа.

...