Can I just use Session["role"] = "theRole", or that would be a bad practice, so I would create my custom authorize attribute where I'm going to look into the Session
+1
A:
It is not bad, but the good principle is to use the Principal object and using the membership provider to answer your queries for Roles.
Kangkan
2010-02-17 16:56:08
I like how you used 'principle' and 'principal' in the same sentence. :x
Nathan Taylor
2010-02-17 17:06:30
Probably you need to re read the sentence. I was talking about a principle, and the principle suggest usage of Principal. You can replace the word principle with "general practice" for clarity.
Kangkan
2010-02-17 17:13:58
+4
A:
Generally anytime you're rolling your own security, it's questionable at best. Is there some reason you can't use the built-in User object and IsInRole method to make your determination?
No Refunds No Returns
2010-02-17 16:57:15
What is it that is questionable, and why? Rolling your own security, or caching Role in Session?
DOK
2010-02-17 16:59:00
to use the built-in IsInRole you must use asp.net roleprovider or create a custom one, but you have to implement the default one which has a lot of stuff that i'm going to need to just leave it as to throw not implement exception
Omu
2010-02-17 16:59:23
Gee ... I've *never* done that and I've used it in at least 10 apps in production. user.IsInRole("MyAdminGroup") ....
No Refunds No Returns
2010-02-17 17:07:34
@Omu You don't need to implement a role provider to use User.IsInRole() you just need to set HttpContext.User to a custom IPrincipal for each request.
David G
2010-02-17 18:03:00
There's nothing wrong with creating a custom role provider that only overrides one method, if that method is all you require for your application to work.
Dan Diplo
2010-02-17 23:37:48
A:
Or if you have custom security roles you can build you own classes holding all the information you need then after login save the whole class to the session to save querying the dabase everytime you need the information
Amgad Fahmi
2010-02-17 16:58:08
A:
Custom authorize attribute is better as it is easily to inject on actions and also there is one place where your authentication/authorization logic resides.
Adeel
2010-02-17 17:04:21
+1
A:
Instead of creating a new Session variable, how about using the existing HttpContext.Current.User? That is in the System.Security.Principal namespace.
It has an array of roles which you can populate, and then test against by using if (thisUser.IsInRole("admin"))...
Just for illustration purposes, here is one way to populate the roles in a manually-authenticated User. In most situations, you will already have the authenticated user.
System.Web.Security.FormsIdentity id = new FormsIdentity(new FormsAuthenticationTicket("dok", false, 30));
string[] roles = { "admin" };
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
DOK
2010-02-17 17:47:54
+2
A:
I would advise against it. .Net already has plenty of built in functionality to implement security features. Don't re-invent the wheel, especially where security is concerned.
You do not need to implement a membership provider. All you need to do is set HttpContext.User to a custom IPrincipal and you can use User.IsInRole("role") and [AuthorizeAttribute(Roles="role")].
I would suggest role information is more suited to the authorization ticket than the session. Storing the data in the session could cause added problems of syncing the session lifespan with the authorization ticket lifespan. The session could possibly expire while the user is still logged in.
David G
2010-02-17 18:00:57