In the past, I’ve captured HTTP errors like this. In this example, I was capturing expired tokens and how the code reacted to it. The code inside the error section will invalidate all information related to authentication.
The above code works but the problem with this is that it’s inefficient especially when implementing this approach on a huge application. If let’s say you have 20 Rest calls like the one above and you needed to edit how the application needs to react, that would be a huge task. Another problem that might happen is that if you forget to edit few files.
The better way or should I say, the recommended way of invalidating authentication information such as stored tokens, ids, etc is via AngularJS’ HTTPInterceptor.
First, we’ll make a factory or service that will house the code for capturing successes and failures. Secondly, we’ll inject this factory into $httpProvider inside .config. Some AngularJS developers will stop here but I usually add a listener inside .run for changing state, and in this case, calling login state to redirect user back to the login screen.
The HTTP Interceptor
Injecting our HTTP interceptor to .config
The Session Factory
This factory is used for authentication. It also takes care of storing user information as cookies. You can use AngularJS’ built in $cookiestore. You can use ngBiscuit. You can ngKookies. You can use localStorage. The method destroy is used to clear the cookies as well as empty out “user” object. You’ll notice that I didn’t put $state.go(‘login’) after $emit. You can but the ideal location for parsing states is in .run. Take a look at “The Listener on .run” below.
The Listener on .run
When you make a broadcast like $rootScope.$emit(‘session:destroy’ ……. ), the listener “session:destroy” will get triggered.
There you go! So what did we accomplish here? We now have a central way of invalidating a user’s token in the frontend and sending him back to the login screen via $state.go(‘login’). We don’t have to rewrite codes that will invalidate tokens. Once this is implemented, you can forget about it and concentrate on other parts of the applications.
I know^3, user tokens are invalidated in the backend. However, we still need to invalidate it in the frontend so we can be given a new token.
Another approach that can be implemented is by adding a code that will re-authenticate a user so it can be given a new token rather than redirecting the user back to the login page. However, this is now part of UX (User Experience). So whichever approach, tell your product owner, “I can do it! “ :)
Hope you learned something from it.
PEACE!