Way to avoid getting provider classes when mvc authentication

Question

Looking for best practices for authentication in MVC, I unfortunately did not find a clear answer to my question. Thinking about the problem, I tried to introduce some principles that may be useful in my design. Well,

• I would like to use the base class AccountController
• I want to put all tables, such as "Users", "Roles" and "Rights" into my own database. But I would not want to implement a standard aspnetdb project (which can be easily obtained using aspnet_regsql)

So the main question is: can I do this without calling abstract classes like MembershipProvider, RoleProvider, etc.? What I would rather not do is implement all the abstract methods from these classes.

The second question is still about best authentication practices, for example. for small projects, for large?

Answer 1

In fact, you can get the basic required functionality without executing each method in MembershipProvider and RoleProvider

Just use throw new NotImplementedException(); as a body of properties / methods that you are not going to use.

My custom membership provider just provides real implementations for

• bool ChangePassword(string username, string oldPassword, string newPassword)
• MembershipUser GetUser(string username, bool userIsOnline)
• bool ValidateUser(string username, string password)

and throw new NotImplementedException(); for others.

Similarly, my custom role provider simply implements

• string[] GetRolesForUser(string username)

With this, I can use basic built-in authorization and authentication without much effort.

Answer 2

From the MembershipProvider MSDN documentation:

When implementing a custom membership provider, you need to inherit the MembershipProvider abstract class.

There are two main reasons for creating a custom membership provider.

• You need to store membership information in a data source that is not supported by membership providers included in the .NET Framework, such as the FoxPro database, Oracle database, or other data source.

• You need to manage membership information using a database schema that is different from the database schema used by the providers that come with the .NET Framework. A common example of this might be the membership data that already exists in the SQL Server database for a company or website.

The emphasis is mine. When you redefine methods, you control how, when, and where all membership information occurs. Your tables, your way.

Note that the MembershipProvider class is abstract. He does nothing on his own. A class that uses the schema you reference is a completely different class.