SPA re-login during session

I am creating a Single Page Application using AngularJS. I am looking at two approaches to handling a long timeout when the server side time expires.

Approach A: Detect during AJAX, Relogin, Resend

  • the user downloads the application initially and subscribes to
  • the user uses the application for a while and then goes into standby mode, leaving the open application
  • server side session ends
  • the user resumes using the app
  • when trying to save data, the angular http interceptor detects a 401 status code response, shows the sign in the modal dialog and if the user authenticates correctly (thus starting a new server-side session), re-uploads the changes to the server

I believe this is technically possible, but the UX can be a little annoying and the implementation can get complicated as there can be many types of AJAX requests that trigger a 401 response (click on a link, edit a field, etc.)

Approach B: Client track downtime and relogin request

  • the user downloads the application initially and subscribes to
  • the user uses the application for a while and then goes into standby mode, leaving the open application
  • for every server response, the browser code starts an idle timer
  • when the interaction with the server is longer than the session expiration period, the browser pre-shows the sign in the modal dialog
  • the user comes back, sees the dialog, and can log in before continuing to use the app.

I think this approach is arguably better UX and also easier to implement since there is no repetition logic.


Do one of these hits as hard? Got a better approach?

+3


source to share


2 answers


They each have their pros and cons, but I use a hybrid approach to get the benefits of both approaches and also to discard the cons. The core of my approach is A, that is, having a server side filter to update session information (expiration, expiration) for every request, but the client also periodically sends keepalive requests based on UI interactions. Each of these stores a response from the server that indicates that the session is still valid (not invalidated by logging out of another tab or SSO). What you need to remember:



  • Approach 1 alone is not sufficient as users are considering reading text and scrolling and clicking on activity. So if you have a client-side functionality clicked on (for example showing popups) that does not send Ajax calls to the server, then the user will be signed out even if they keep clicking on that button.

  • Approach 2 on its own is also insufficient as you only rely on user activity in the current user tab (if you are not using browser storage) and not on server data. Problems arising from this: a) user logs out to another tab, but still logs in in another tab; b) in many secure cases you will need to inject your application using one sign in third party applications, then you really need to be signed as long as the user is active in another application.

0


source


Specific Approach A. But a more elegant way is to use $httpProvider.interceptors

.

Right after Angular launches your app, configure your app like this:



app.config(['$httpProvider', function ($httpProvider) {
    $httpProvider.interceptors.push(['$q', function ($q) {
        return {
            'responseError': function (rejection) {
                if (rejection.status === 440) {//I prefer to use 440 to indicate the user is timeout.
                    //window.location.href = "/login"; redirect to your login page
                }
                return $q.reject(rejection);
            }
        };
    }]);
}]);

      

Thus, the redirect method can be injected into the $ http method . Anytime the server sends code , this method will be executed first. 440

0


source







All Articles