views:

95

answers:

1

I'm working with ASP.Net MVC as well as DynamicData and I need to add role-based security.

Should I implement this via:

  • IHttpHandler with custom actions that check if the user is authorized?
  • Or should I be using a RoleProvider?
  • Or perhaps some combination of the two?

If the RoleProvider is a viable option, when would I ever need to extend the abstract RoleProvider base class vs. using the ones included. MSDN says you would only extend this class if "You need to store role information in a data source that is not supported by the role providers included with the .NET Framework." Please expound on this. Explain how this would work under circumstances where I don't need to extend the base class but instead use the included role providers. What data sources are supported by the included providers?

Also, would your answer to these questions be different for ASP.Net MVC vs. ASP.Net DynamicData?

A: 

All MSDN is saying here is "we wrote this stuff for you, tested and debugged it, please use it".

The default role providers work great if you spend some time to set them up. Implementing your own isn't too hard either.

I'd answer both pretty much the same. With MVC your setting an Authorize attributes on your Controller and/or Controller actions. With Dynamic data your setting things up with inside the web.config file.

jfar