So far, our backend doesn’t have any kind of authentication control, which doesn’t happen (or at least it shouldn’t happen) in the real world. The backend was modified to perform authentication, but this was reflected in the frontend because, if we tried to log in, the following error would occur:
ERROR Error: Uncaught (in promise): HttpErrorResponse:
{“headers”:{“normalizedNames”:{},”lazyUpdate”:null},”status”:401,”statusText”:”Unauthorized”,”url”:”http://localhost:3000/diary”,”ok”:false,”name”:”HttpErrorResponse”,”message”:”Http failure response for http://localhost:3000/diary: 401 Unauthorized”,”error”:{“message”:”Unauthorized”,”statusCode”:401}}
This error means that our request was rejected by the server because it was not authorized. That’s because our server implements a very common form of security that consists of asking for an authorization token in every request.
This token is created when the user logs in to the application and it must be passed in the header of the HTTP request.
We’ll fix this problem first by making a change to the AuthService service:
export class AuthService {
private httpClient = inject(HttpClient);
private url = ‘http://localhost:3000/auth/login’;
#token?: Token;
login(loginForm: Partial<LoginForm>): Observable<Token> {
return this.httpClient
.post<Token>(this.url, loginForm)
.pipe(tap((token) => (this.#token = token)));
}
get isLogged() {
return this.#token ?
true : false;
}
logout() {
this.#token = undefined;
}
get token() {
return this.#token?.access_token;
}
}
First, we change the access mode of the token attribute. We are using the # symbol, which is the way to declare a private attribute in standard JavaScript. We want the token to be read by the other component but never overwritten, and using the token ensures that this happens even if the consumer class forces manipulation.
We change the class to the new attribute name and, at the end, we create the token() accessor method to return the token stored by the service.
We’ll refactor the ExerciseSetsService service to send the token in the request that returns the diary items:
private authService = inject(AuthService);
private url = ‘http://localhost:3000/diary’;
getInitialList(): Observable<ExerciseSetListAPI> {
const headers = new HttpHeaders({
Authorization: `Bearer ${this.authService.token}`,
});
return this.httpClient.get<ExerciseSetListAPI>(this.url, { headers });
}
Here, we create a header using the accessory class of Angular, HttpHeaders, passing the token in the Authorization attribute. Then, we pass this header in the get method of Angular’s HttpClient service.
When we run our application again, it works again (Username is mario, and Password is 1234):
Figure 8.1 – Gym diary home page
This approach has a problem, as we would need to replicate this operation for all of the service’s methods, and as our application grows, we would need to remember to do this token handling.
A good software architecture should think about new team members with different backgrounds and even the creation of new teams as the project grows. Therefore, this type of transversal requirement of our system must be treated in a more intelligent way.
Enter Angular Interceptor, which is a service of a specific type to handle the HTTP request flow. This component is based on the design pattern of the same name, which aims to change a processing cycle.
Let’s illustrate this pattern with the following diagram:
Figure 8.2 – Interceptor design pattern