Last post May 16, 2019 11:47 AM by yogyogi
May 02, 2019 10:35 PM|Yossu|LINK
I'm new to ASP.NET Identity, and am struggling with roles. My previous experience in in desktop apps (where we obviously couldn't use ASP.NET Identity, and mainly rolled our own roles), and we usually added an enum for
the roles. This enabled us to refer to them unambiguously in code.
ASP.NET Identity seems to require roles stored in the database. My main issue with this is that we can't guarantee that everyone (all developers, the test and production databases) will have the same data in our databases. By using an enum,
the data is hard-coded in the code, so no possibility of ambiguity.
A secondary (but still very important) issue is that roles seem to rely on you using hard-coded strings...
[Authorize(Roles = "SomeRole")]
public IActionResult SomeAction() =>
This seems brittle. It's all too easy to mistype the role name, and what if we want to change the name? We'd have to hunt down every instance of the hard-coded string and change it.
To clarify, roles are being used to restrict access to certain areas of the web site. We will have a fixed set of roles, which will rarely change. If they do change, the code will need to change with them, so dynamic access to roles (eg via a CRUD section
of the site) is pointless.
Can we do this? If not, how do we get around the issue of knowing how to refer to roles that may not exist?
May 03, 2019 02:07 AM|Nan Yu|LINK
Hi Yossu ,
You can firstly list all the roles in database with interacting with the RoleManager :
Then you could create your enum type to store the role id and name , so that the enum could be used in entire your application .
May 03, 2019 02:47 PM|Yossu|LINK
Thanks for the reply, but I don't see how it helps. You're still relying on database values for the roles, and as I pointed out, these might not be the same across everyone's database.
Thanks anyway, any other ideas?
May 06, 2019 01:58 AM|Nan Yu|LINK
If you don't want to rely on database , you need to crate database scripts to manually create roles in each database , you can create roles in table `AspNetRoles` , and link the user and roles in table `AspNetUserRoles` , but with that way , if you changed
the hard-code roles in your application , each of your database roles should sync to get the new values.
May 07, 2019 08:56 AM|PatriceSc|LINK
It really depends on what you want to do exactly. Do you have an idea about the kind of role customization you would expect for a given database (ie how a user could create a role and then take that new role into account in your app). If you want to "group"
users it might be something you'll keep separate from roles (and assign to users all the roles attached to those groups ?).
This is for .NET Core but you could still have a look at https://docs.microsoft.com/en-us/aspnet/core/security/authorization/introduction?view=aspnetcore-2.2 that
could help maybe to better narrow down which kind of scenario you need.
Edit: or for now using constant strings could be enough (?) ie the following should work :
[Authorize(Roles = KnownRoles.SomeRole)]
May 07, 2019 04:46 PM|Yossu|LINK
Thanks for the reply.
As I explained in my first post, we will have fixed roles that will be created when the web site is first created, and rarely changed. If they are changed, it will involve a corresponding code change. We are not modifying roles from the
I think your last line gives me what I need. I don't seem to be able to avoid storing the roles in the database, but by using a constant for the role name, we avoid the problem of people having differences in their databases. I thought you needed to refer
to roles by their ID, which could be different for different devs, but it seems we can refer to them by role name, and if we don't have a facility in the site for modifying them, the chances of this going wrong are negligible.
May 16, 2019 11:47 AM|yogyogi|LINK
In ASP.NET Identity you can definitely create as many hard-coded roles as you want. Kindly check this doc - How to work with Roles in Identity System