Juri Strumpflohner

Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, occasionally speaks at conferences and holds training workshops.

Learn how to create a custom structural directive in Angular that checks against user permissions

So our use case is to create a directive, which shows/hides elements on the page based on our currently authenticated user's permissions. In this article we will go over a very simple use case, but which could easily be extended and used in a real production application. By creating such directive we'll also take a deeper look at the syntax that Angular's ngIf and ngFor directives use.

Our User object

As you can see, our permissions is a simple array of strings which will most probably come from our backend API when we fetch the current authenticated user. In our toy example here, I’m having a user.service.ts which deals with our application user. It allows us to set a new user and to subscribe to changes on our authenticated application user.

Note, if you don’t place the * in front, you won’t be able to inject the TemplateRef<any> or ViewContainerRef into your directive.

Implement the permission logic

Now it should be pretty straightforward. We now know how to show/hide an element. All we have to do is to grab a reference to our UserService, get the current authenticated user and perform the permission check logic.

Our directive could look like this:

<div*hasPermission="['can_write', 'can_read']">
Only users with "can_write AND "can_read" permissions can see this.
</div>

You see we pass in the permissions one requires to see the element to our *hasPermission directive. Note the @Input() hasPermission which is where we get the array of permissions from the outside. We then subscribe to the userService.currentUser observable and whenever we get another permission passed in or a new user comes around we call updateView() which checks the permissions and then acts accordingly.

Allow to perform logical OR comparisons

From the example before you can see that currently the user has to have ALL permissions defined on our hasPermission directive. What if we wanted to perform a logical OR? That would allow to define an element where the user only needs to have one of the permissions.

In order to pass in the operator, you’d add another @Input() right? If you try something like this, you will not succeed, though.

That’s because you cannot have other directives together with structural directives on the same element (that is, our *-prefixed ones). The reason is that the * is actually just a shortcut for writing it like

That’s it. So now that we know how to get our boolean operator inside our directive, we just need to adjust our permission checking algorithm to take that into account.

Conclusion and final example

Here’s the full running example of a potential permission directive. Note, this is just an example, nothing to copy & paste into your production code. But you can definitely take it as a starting point.

But hey, we’re running this in the browser. How can this be secure?

You’re right, it’s happening in the browser, at our user’s computer, in JavaScript. That’s why it’s important to note that we’re not strictly talking about security here but rather this is presentation logic and UX. We want to hide elements the user wouldn’t be able to do anything with anyway. In case a user would be able to “break” into such hidden element, any calls to the server made by those components should obviously not return anything. Because further security checks about whether the user has the permission to read/see the data is done on the server side.