I am developing an application for which I have a user area and an admin area. I have separated these into separate Angular 2 modules. I have successfully implemented lazy-loading so that the admin module can be loaded only when '/admin' is requested by the user.
From the Angular 2 documentation, I see that I can specify a "canLoad" guard like so:
{
path: 'admin',
loadChildren: 'app/admin/admin.module#AdminModule',
canLoad: [AdminGuard]
}
and implement a function canLoad inside an AdminGuard class like so:
canLoad(route: Route): boolean {
return this.authService.isAdmin();
}
(where isAdmin() could make a call to the backend API which would return the role of the current user or something like that)
But does this actually prevent any non-admin from loading the AdminModule? Unless I am misunderstanding, all of this code is located on the client, so is there anything to prevent the client from modifying the "canLoad" method so that it always returns true? Like so:
canLoad(route: Route): boolean {
return true;
}
Thus allowing the client to load any module they want.
Obviously any calls to the backend API that require admin status will be protected, but it seems like any user will be able to view the admin UI, which just seems a little weird to me. Can somebody clear this up for me?
This is a great question and I was curious if anyone did have a detailed answer for this. So I found this link that had a pretty great conversation going.
Angular 2 Reddit Article
One comment that really stuck out to me was this one.
Speaking in SPA, generally html templates and your js files will be out in the open for anyone care enough to check. Your SPA will speak to your server in data (read:json) only, the templates will then be populated with this data on client side. so your primary concern is protecting this API. Sessions, cookies, tokens, all are means that still valid here. I myself uses tokens to authenticate and authorize. An API request would contain server signed token, which is then verified and from which roles and credential are extracted, then used to determine that the user is authorized to make that request. Failed check will return 401-unauthorized to the client. On angular side, we save token we received after successful login then use it for subsequent requests. I also decode the credential and roles, and with it display user info and authorize routes. Routes guard in angular is achieved through CanActivate interface, which you can chain multiple of: { Path: 'protected', CanActivate: [LoggedInGuard] },{ Path: 'supersecret', CanActivate: [LoggedInGuard,AdminGuard] } ...etc But client side (read:angular) guards is ultimately UX problem, not a security means. A knowledgeable hacker can just mess with the variables with dev console, or bypass it altogether with straight api call. It's pretty much to show users what error happened and navigate somewhere else etc.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With