Do I need to implement all the required methods on the MembershipProvider and RoleProvider if writing a custom one to use the AuthorizedAttribute in ASP.NET MVC?
There are a few features that I don't want to implement like CreateUser or 'DeleteRole` because they violate the system I will be authorizing/authenticating against.
No, you don't need to implement everything if you never use this functionality. Throwing a NotImplementedException is always a good way to indicate this.
I am currently doing the same thing and you don't have to implement all the methods.
You might want to look at the following website.
http://theintegrity.co.uk/2010/11/asp-net-mvc-2-custom-membership-provider-tutorial-part-1/
Great tutorial for implementing a custom membership provider with ASP.NET MVC!
No you don't need to implement all methods for the MembershipProvider or RoleProvider; if you never use the API for creating, updating, or deleting, then you could throw an exception when used. These are there in case you do modify user data, and are also used by the Administration web site option in Visual Studio. So if you use that web site, it quite won't work as expected as it expects these provider methods to be present.
But if all you do is use the controls, then it would be handy to research which API methods these control use and make sure that you have implementations for those. What I mean is that Login control uses ValidateUser for sure, and may use GetUser too. It may also call UpdateUser to update the failed logon count, last login date, etc.
HTH.
Related
I'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the Roles class.
The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.
I use ASP.NET MVC 3 for an application which makes heavy use or Users and Roles.
To create a user and assign role(s) I use the standard process via ASP.NET Membership.
Throughout the entire app I use NHibernate for the underlying data access except the places were the default MembershipProvider and RoleProvider implementations are used (inside the AccountController which delegates calls to those implementations).
I would like to use NHibernate in order to be able to read/edit/modify the values on that tables which are managed by ASP.NET Membership.
I found two solutions:
Write a custom NHibernate implementation for MembershipProvider and RoleProvider (or even use this one). That's the hardest path.
Map only the tables (as described here) and then use NHibernate directly (although any default actions from AccountController will still handled by the default providers).
Any suggestions/recommendations?
I've used the custom provider you link with pretty good success. I did make a few changes to it, so that it would use a single session for its lifetime.
If you want to use ASP.net membership I think that approach is your best bet, mainly for portability (it doesn't rely on any SP's being present in your database). I'm currently using the modified provider from that link against MSSQL and Postgres with no problems, and I've used it against MySQL as well.
I am using asp.net 2.0. I have been using asp.net membership provider for user management. But I think this would be more efficient if I could do this without using role and membership provider provided in asp.net. In fact I see bulky markups generated when I add login control,
createuser control etc. in an asp.net web page.
By saying user management, I am referring to the overall login, user activity tracking, password reset/retrieval, role management in an asp.net web application. And I want to implement efficient way to accomplish this.
Any suggestion would be appreciated.
What exactly bothers you? Server-side code, or the HTML which gets served to the client?
If former, then you can implement your own providers or just reinvent the whole system from scratch (which I do not recommend, but it might be worth it in some scenarios).
If latter, just write your own set of controls that use Membership API.
As far as "efficiency" is concerned, you're not clear in what "efficient" means to you.
Most (all?) of the membership controls support templates, which means you can customize the markup they generate to the client.
See this tutorial to get you started: A Crash Course on ASP.NET Control Development: Template Properties
As for the database hits, I don't think it's a huge problem, but if you're concerned I'd suggest load testing it to make sure. Also, if you set CacheRolesInCookie to true, you can eliminate some of those database calls.
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?
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.
I have an ASP.Net Web Forms application in which I'm using forms-based authentication with Membership and Role providers, which is fine for authenticating and controlling access to directories and/or files. Now I find myself needing to control read, write and delete access on individual entity instances, for example being able to update or delete an instance of a customer. I've been trying to think of a good way to implement this but I don't really know where to start. I read about the Authorize attribute in ASP.Net MVC and thought it would be nice to have something analogous--decorating methods the way you can controller actions in ASP.Net MVC. I don't know of any out of the box way to accomplish this in the Web Forms world though, and don't know of any frameworks or other tools that might help me move in that direction. Any suggestions, both in terms of existing solutions and/or how to design my own implementation would be greatly appreciated.
The easiest way is to demand that the user is a member of the role(s) required for the method in question with PrincipalPermissionAttribute.
[PrincipalPermission(SecurityAction.Demand, Role="Supervisor")]
[PrincipalPermission(SecurityAction.Demand, Role="Owner")]
public void DeleteSomething() {...}
Note that this means Supervisor OR Owner can DeleteSomething().
I don't think "PrincipalPermission" is a good approch.
What If, I need to allow DeleteSomthing() for another role?
similarly, If I need to remove existing role for DeleteSomthing()?
The only way is changing the attributes at code level. This is not at all feasible for big projects.
I am also looking for a nice solution.