By default ASP .Net MVC allows developers to customize the way the framework handles user membership. Back in the old days when people used ASP .Net Webforms the main way to do this was to implement a custom membership provider.
ASP .Net MVC introduced a new way to do this, using a series of interfaces. In the old way of doing things, a developer had to implement a single abstract class called "MembershipProvider". The new approach pretty much split up this big class into multiple simpler interfaces each providing a part of the functionality of the whole membership system. It is called Identity. It also introduced better support for 3rd party authentication using external systems such as Facebook, Twitter and so on.
It is actually built over the old membership system and is available in ASP .Net Core too but it might differ in some ways.
The most important interfaces are:
ASP .Net MVC introduced a new way to do this, using a series of interfaces. In the old way of doing things, a developer had to implement a single abstract class called "MembershipProvider". The new approach pretty much split up this big class into multiple simpler interfaces each providing a part of the functionality of the whole membership system. It is called Identity. It also introduced better support for 3rd party authentication using external systems such as Facebook, Twitter and so on.
It is actually built over the old membership system and is available in ASP .Net Core too but it might differ in some ways.
The most important interfaces are:
- IQueryableUserStore and IUserStore, which store the users registered on the website, including their password if available
- IUserRoleStore, which stores the roles on the website and the what users belong to them
- IUserLoginStore, which stores external logins such as Facebook, LinkedIn and so on
They are actually part of the repository pattern implementation. Each of them stores and handles separately some of the entities involved in ASP .Net membership such as the roles, users and profiles. Pretty much all of them have to be implemented in order for the membership system to work properly. In general, they implement CRUD operations. They also have special generic parameters, TUser and TKey. TUser represents the user entity type used by the framework and TKey represents the type of the unique ID of each user stored in the database. Their only real usage is to specify what kind of key type to use in order to identify each entity stored in these repositories. The key type can be for example long or string.
This is how the IUserStore interface looks like and methods it exposes:
The methods exposed in these need to the implemented in a class which will be a concrete implementation of the interface. Unfortunately, the ASP .Net framework doesn't use these interfaces directly which makes things a bit more complicated. For this, there exists another class called UserManager which brings together all of these interfaces and uses the functionality exposed by them.
But here there is a bad design choice. The UserManager class takes just a class which implements IUserStore as a parameter. You can't pass all the other interfaces. It expects all of the interfaces mentioned above to be implemented by a single class and pass that as a parameter to the UserManager class. This class should be derived from which makes things even more complicated. Again a bad design choice here. It should also provide a static method to create instances of this clas like bellow:
So a big, unified interface should be made which includes all of the interfaces as shown below:
Because of the reason mentioned above, a single big class needs to be made to implement the big interface and all the repositories or "stores" for the membership functionality implicitly.
After this, all of these classes need to be registered somehow in the framework in order to be used by them. Unfortunately, there is bad design choice again here. All of these components have to be registered in the system in different and sometimes obscure ways.
The class which implements the repositories has to be registered using dependency injection. In the example below NInject was used but anything works here:
This has to be done just once at application startup. There are a lot of ways to achieve this like using Global.asax.cs. Another way would be using the startup attribute OwinStartupAttribute on classes which specify methods to be executed before the website starts. Having so many ways to do the same thing seems like a bad design choice to me.
The UserManager class has to be registered differently because it needs a special kind of life cycle as in the example below:
Only the first line of code in method contained in the example above registers the actual user manager. The rest of the code configures user authentication. It just tells the system to use a method ApplicationUserManager.Create that creates and returns instances of the user manager. The method can be found in an example above which contains the code for the actual user manager. Again, this needlessly complicated and a bad design choice. The only way to register this is using the
OwinStartupAttribute because it needs an IAppBuilder instance to register the user manager. This seems like a really bad idea to me because it doesn't use the standard dependency injection mechanism. I like software to be uniform because it is much more easier to understand.
Once they are registered in the system, they can be used by controllers which require membership functionality. They can use membership in various ways. For example, a controller depends on the membership functionality just by using the Authorize attribute on a controller action or on a controller itself in case it needs to restrict access only to logged in users or to users in specific roles.
Or a controller can use membership directly using the UserManager class or a derived class from it like in the example bellow:
In the example above, the big class which implements CRUD operations for membership entities is automatically passed to the constructor through dependency injection. The UserManager can be passed both through standard dependency injection or through another weird mechanism based on OWIN context which isn't the focus of this post.
The second part of this tutorial will become available later. A working example of an ASP .Net MVC website used in this post which uses customized membership can be found here: https://github.com/Alecu100/NetBazaar
The methods exposed in these need to the implemented in a class which will be a concrete implementation of the interface. Unfortunately, the ASP .Net framework doesn't use these interfaces directly which makes things a bit more complicated. For this, there exists another class called UserManager which brings together all of these interfaces and uses the functionality exposed by them.
But here there is a bad design choice. The UserManager class takes just a class which implements IUserStore as a parameter. You can't pass all the other interfaces. It expects all of the interfaces mentioned above to be implemented by a single class and pass that as a parameter to the UserManager class. This class should be derived from which makes things even more complicated. Again a bad design choice here. It should also provide a static method to create instances of this clas like bellow:
So a big, unified interface should be made which includes all of the interfaces as shown below:
Because of the reason mentioned above, a single big class needs to be made to implement the big interface and all the repositories or "stores" for the membership functionality implicitly.
After this, all of these classes need to be registered somehow in the framework in order to be used by them. Unfortunately, there is bad design choice again here. All of these components have to be registered in the system in different and sometimes obscure ways.
The class which implements the repositories has to be registered using dependency injection. In the example below NInject was used but anything works here:
This has to be done just once at application startup. There are a lot of ways to achieve this like using Global.asax.cs. Another way would be using the startup attribute OwinStartupAttribute on classes which specify methods to be executed before the website starts. Having so many ways to do the same thing seems like a bad design choice to me.
The UserManager class has to be registered differently because it needs a special kind of life cycle as in the example below:
Only the first line of code in method contained in the example above registers the actual user manager. The rest of the code configures user authentication. It just tells the system to use a method ApplicationUserManager.Create that creates and returns instances of the user manager. The method can be found in an example above which contains the code for the actual user manager. Again, this needlessly complicated and a bad design choice. The only way to register this is using the
OwinStartupAttribute because it needs an IAppBuilder instance to register the user manager. This seems like a really bad idea to me because it doesn't use the standard dependency injection mechanism. I like software to be uniform because it is much more easier to understand.
Once they are registered in the system, they can be used by controllers which require membership functionality. They can use membership in various ways. For example, a controller depends on the membership functionality just by using the Authorize attribute on a controller action or on a controller itself in case it needs to restrict access only to logged in users or to users in specific roles.
Or a controller can use membership directly using the UserManager class or a derived class from it like in the example bellow:
In the example above, the big class which implements CRUD operations for membership entities is automatically passed to the constructor through dependency injection. The UserManager can be passed both through standard dependency injection or through another weird mechanism based on OWIN context which isn't the focus of this post.
The second part of this tutorial will become available later. A working example of an ASP .Net MVC website used in this post which uses customized membership can be found here: https://github.com/Alecu100/NetBazaar
Comments
Post a Comment