If you're working on an application that allows users to register an account, you've likely encountered the issue of role-based security.
What is role-based security and why do we need it?
Say you're working on an application that allows users to share webcomics with each other. You've already built in the features that allow the user to securely upload photos to your database, and you've implemented features that allow users to register an account and log in.
But now you need to ask what features should be accessible to any user regardless of if they've registered an account, what features should be accessible to registered users, and what features should be available to privileged users.
This is where role-based security comes in.
For the sake of my illustration, let's categorize users into four tiers of access:
- anonymous (unregistered) users
- registered users
By default, my application allows any user to see, interact with, and use any of the pages on my application.
But what pages should anonymous users be able to see?
As a general rule, landing pages and displays of publicly-available data are fine for anonymous end-users to see.
Some developers may maintain applications that contain a large amount of sensitive data, however, which means it might be appropriate to refactor the application's default authorization.
We can do this with some interplay between the
But more on anonymous users later.
Let's back up and talk about the
If I want my application to handle uploads, it's in my best interest to deny anonymous users access to some of my views. I can do this with a simple keyword called "Authorize"
To prompt a user to register and log in to see a View, I need to access the controller that handles the get and post http requests for the Views I want to authorize.
To illustrate, let's look in my ToonSpace webtoons application, and access the Uploads controller.
I don't want anonymous users to be able to upload to my website, so I need to make a small change under the "get" action by adding
[Authorize] above the action.
This simply ensures that only users who have registered an account and are logged in can access the "Create" view to upload something new to the database.
I've grouped moderators and administrators together because the code for my Moderator and Administrator permissions is essentially the same. The only differences are discretionary. I grant some permissions to both roles and others to just the Administrator.
So how do I grant special permissions to these roles?
Just a few simple lines of text:
To authorize a moderator as well, I simply add a comma:
[Authorize(Roles = "Administrator, Moderator"]
I've created the structure for role-based security. Any user may create an account and log in, and anonymous users are not allowed to post anything. But what if I want to set the default to allow anonymous users to post something (like a comment)? I can simply use the
And what about these Administrator and Moderator roles? How do I differentiate between which users are in these roles? Should anyone be allowed to sign up as an Administrator or Moderator?
I'm sure you already know, dear Coder, that allowing the user to sign up as an Admin is probably not a great idea. What I can do instead, however, is "seed" a designated user as an Administrator or Moderator.
But that will be the topic of my next letter.
If you'd like to read more letters, you can find them at dear-coder.com.
Until next time, godspeed in your keystrokes.