8

I have always stayed away from asp.net membership as it seemed bloated, and (at the time) untestable. In the case of asp.net MVC specifically, does anyone use an alternative solution for assigning roles to users, and storing some addition information for the logged in user? Any recommendation? Is it crazy to just roll your own, just implementing the functionality you need?

Jason Berkan
  • 8,734
  • 7
  • 29
  • 39
Roco72
  • 131
  • 3
  • If you need an alternative then you probably have some reasons... could you share them with us? What's missing in asp.net membership that you want to use? – Łukasz W. Aug 24 '10 at 21:29
  • 3
    I'm not sure how it's "bloated". If anything, it's a little lean on the roles side. – Greg Aug 24 '10 at 21:31
  • You can add columns to the tables generated by aspnet_regsql, and it works just fine. You can then refer to the tables in something like an entity model if you want. That way, you can still use ASP.NET's membership provider to the extent it works for you, but you can benefit from the additional information you are storing also. – Andrew Aug 24 '10 at 22:17
  • What ARE you using? There are many solutions which expand other tools you may be already using. For example, if you're using NHibernate for data access: http://stackoverflow.com/questions/512922/how-do-you-handle-membership-roles-when-using-nhibernate – synhershko Aug 24 '10 at 22:26
  • It's not crazy to roll your own. The way I see it, it would be a bigger bother to use ASP.NET membership than to write my own. Once you write it, it can be easily reused for other projects. – Necros Aug 25 '10 at 00:21

2 Answers2

3

ASP.NET membership uses a provider model for the storage. SqlMembershipProvider inherits encrypting/hashing password functionality from the abstract MembershipProvider class. But you could also inherit from MembershipProvider and get that functionality in a custom provider if you wanted.

If you use the SqlMembershipProvider, you get a fully working membership database with full password management (checking, changing, resetting, invalid password attempts) and user management (CRUD ops, locking out users).

All of that is at an API level. You can create whatever UIs you want against the API.

Using the SqlMembershipProvider doesn't require you to use the Roles Provider or the Profile Provider or any of that other stuff, and you can roll your own for those things without impacting membership. At the very least I would recommend using the well-tested SqlMembershipProvider as the core of your security for the basic stuff.

Greg
  • 16,540
  • 9
  • 51
  • 97
  • I guess the issue with that is when you need to extend it. Or, your existing schema doesn't match the SqlMembershipProvider db. – Roco72 Aug 25 '10 at 17:56
  • extending the SqlMembershipProvider could be problematic. Personally I use the SqlMembershipProvider in an application that primarily runs on Oracle. Those tables are just sitting in their own little database not worrying about the main business database and it seems to work well for me. – Greg Aug 25 '10 at 18:59
0

I have successfully implemented DotNetOpenAuth as a membership and role provider. It is not a full implementation but handles most common scenarios.

They provide VS templates to get you started.

Sky Sanders
  • 36,396
  • 8
  • 69
  • 90