Services and Business Logic and Handling User Authentication in Angular JS
Categories: Angular Angular JS
Services and Business Logic and Handling User Authentication in Angular JS
Not all AngularJS services connect to REST services. Services can also contain business logic that is used by multiple controllers. As I mentioned before, if the business logic can be moved to a REST service, that is where it should be defined. Defining business logic in REST services assures that the same logic will be readily available to all client-side applications.
Often, however, it is not possible to move all business logic to REST services. Often that same business logic is needed across multiple controllers. That is where AngularJS nonREST services come in handy once again. In this chapter we will look at several examples of where AngularJS non-REST services are useful.
Take, for example, a situation where a user needs to authenticate across multiple REST services. One way to do that is by using Basic Authentication, where the user’s username and password are passed to a service as a token in the HTTPS header during a service call.
The token is in the form of “username:password” and encoded with base64.
As we know, a REST service shouldn’t hold state, and holding a user’s credentials in a session variable on the server is a serious security concern. Using a session variable to hold authentication state on the server side is usually not acceptable in most REST service designs. AngularJS services are great for handling such situations.
Handling User Authentication
First, we need a way to validate a user’s credentials over HTTPS. The following code shows a REST service used to authenticate a user:
/* chapter8/ login REST service URL from services.js */
POST: https://www.micbutton.com/user/login
Here is the JSON request for the REST service:
{
"username":"ken",
"password":"password"
}
And here is the JSON response for the REST service:
{
"authenticated":true
}
This particular service call would normally be open to any user and therefore would not require authentication. Allowing all users to access this service uninhibited means any user can try to validate against the service. If there is a possibility of abuse, the service could be secured at the network level, or a challenge and response system could be used to discourage unwanted users.
Once a user makes a call to the login service and the user’s credentials are validated, it is the job of the AngularJS application to temporarily store those credentials. It is also the job of the AngularJS application to direct the user to a login page when the user has not been authenticated. AngularJS non-REST services play a major role in this process.