Discitur Project

One of the aspect you have to face in a SPA Authentication is the Page Reload management, that’s how to keep the “authenticaed session” alive even during the page reload. Following are the steps used in my implementation:

 

1. angular authentcation service called from different login forms (#1)
2. the login method calls an “anonimous” (not authorized) API service which check for Username/Password. For security reasons it could be preferable to use HTTPS protocol. (#2)
3. If data pass the account validation check, the service returns an encrypted token that contains account and validation period information (#3)
4. the token is saved in localStorage (#4)
5. in the login service callback it’s called an authenticated back-end service to get/complete user data (#5)
6. the call passes through an interceptor that sets the header for the management of authenticated calls, if this authentication token exixts (#6)
7. the service, if token is valid, returns the requested data, otherwise it returns a 401 response (Not Authorized resource) and the token is removed from the localStorage(#7)
8. if the request is successful, the user data is retrieved and update the “user” object of the authentication service, which is controlled in the application anywhere you want to manage the logic related to the authenticated session (#8)

  If you reload the page (or you close the browser and reopen it after a few days on the application), initializing the authentication service check for the existance of the authentication token and, if exists, call the service for retrieving user information, linking in step 6 of the previous list. An highlight of this service is:

 

The complete code is on github: https://github.com/williamverdolini/discitur-web/blob/sprint3/app/modules/user/UserService.js

  The management is straightforward and clear from my point of view. The only aspect that I was not able to clarify is related to the management of $http service’s callback (core angular). The thing I found was that although the REST service returns a status 401, $http service calls the success callback… while I would have expected had called the error callback. The official documentation seems to me to give me reason… but I did not find major findings in this report on the net … someone can enlighten me?

Update

The problem of callback was becoming more frequent and I then had to deal with, stopping the rest. I did a lot of research to see if others had had similar problems and the first step to do in this kind of problems is Stackoverflow.

I was doubly unlucky, because yes, I found a post expressing my exact same problem, too bad that the solutions proposed had nothing to do with mine… Effect? Nearly a week of (“useless”) discussions on the operation of IIS, about the HTTP standard, about .Net WebAPI.

The problem was that I was wrong in using a intercpetor Angular.js.

Techniques for Problem Solving deserve a separate article (or maybe books…), but the thing I learned from this experience is to remain lucid and critical about what is really happening in the system without being distracted (too much) by forum post. It is not easy…especially for one who is “Stackoverflow-addicted” like me.

Open and debug Angular.js is quite educational, but it makes me seasick… so I added my own little contribution to the Stackoverflow community.