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

В нашей среде, чтобы обеспечить наилучший 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. Для эффекта размытия добавьте в body/main класс с [class.blur]="authenticationService.sessionTimeoutIn <= 0"
6. Для еще большего удобства создайте div, который толкает main/body и входит в представление сверху, содержащее это, которым можно управлять с помощью <div *ngIf="authenticationService.sessionTimeoutIn > 0 && authenticationService.sessionTimeoutIn <= 2"></div>:

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

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

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

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

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

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

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