I want to use asp.net-mvc to write a website, I am quit new to the framework And I am not sure if using MembershipProvider Class is a good idea or not.
Or it is better to implement it by myself.
Could you please tell me what are MembershipProvider drawbacks? and if I use it would I have control over it.
Regardless of the purpose of your website, using MembershipProvider basically gives you flexibility in providing the control of most basic user account management (like login, forget pwd, register, etc).
By inheriting from MembershipProvider class, you are then are exposed to various methods and properties to support membership system. You still have to write code for the implementation of your choice, of course, but eventually you can use multiple or swap them via web.config.
Related
I am a bit confused with customizing UserManager and UserStore.
Out of the box solution comes with EF implementation and i don't want to use EF but my own DAL that uses MSSQL. I want to have Claims based security where one of the users Claims will be roles.
What i am confused with is the overall process i should do. From what i undestand so far is that i need to make my own
CustomApplicationUser : IUser
CustomUserManager : UserManager<CustomApplicationUser>
CustomUserStore : IUserStore, IUserClaimStore
Questions:
Am i on the right track with this?
I want to use IsInRole() method on my CustomUserManager but not sure how to do it with Claims. I am aware there is IUserRoleStore.IsInRole() which default UserManager calls in UserManager.IsInRole() but i don't want separate Roles table in my DB. What i want is Claims DB table with one of ClaimType being Role and that UserManager.IsInRole() uses that.
Now, i am not evet sure why would i ever need UserManager.IsInRole() method? Would i actually need to have something like custom ClaimsIdentity SignInManager.CreateUserIdentityAsync() and within that one call my own implementation of filling in all users info including Claims?
It seems a bit confusing for me and i can't seem to find some clear documentation about it so if anyone could shed a bit of light on it i would highly appreciate it!
Instead of just copying I will just point you to following article: Overview of Custom Storage Providers for ASP.NET Identity.
Take a look at this, it should give you nice overview of how identity works in ASP.NET. It's also good for choosing what you want to override and customize in your application.
I have an ASP.NET MVC app that I'm working on. I'm using a custom MembershipProvider (MyCustomMembershipProvider) to access membership information because we already have a database with our own schema that I need to use.
I am using classes similar to the NerdDinner 2 example where I have an AccountMembershipService (implementing an IMembershipService) that contains a MembershipProvider so I can inject a different mock provider. However, I have extended the MyCustomMembershipProvider with a few different methods for CreateUser and ChangePassword. These methods are not available in the MembershipProvider unless you know it's a custom one.
Am I going about this incorrectly? Do I need another layer that is an interface that includes my new provider methods?
I'm not fully sure I understand what your problem is. If you're using a wrapper interface over the MembershipProvider, then it shouldn't matter what methods the provider implements because your app is only using the interface, and you can change the interface to whatever you want.
Or are you asking how you would call your custom methods from your Custom provider? If so, then the whole bit about mocking and what not are just red herrings, because it has nothing to do with the problem.
If that is indeed your problem, then you would simply cast the Membership.Provider method to the type of your provider. Something like this:
var myProvider = Membership.Provider as MyCustomerMembershipProvider;
myProvider.CreateUser(...);
I have an existing ASP.NET application with lots of users and a large database. Now I want to have it in MVC 2. I do not want to migrate, I do it more or less from scratch. The database I want to keep and not touch too much.
I already have my database tables and I also want to keep my LINQ to SQL-Layer. I didn't use a MembershipProvider in my current implementation (in ASP.NET 1.0 that wasn't strongly supported).
So, either I write my own Membershipprovider to meet the needs of my database and app or I don't use the membershipprovider at all.
I'd like to understand the consequences if I don't use the membership provider. What is linked to that? I understand that in ASP.NET the Login-Controls are linked to the provider. The AccountModel which is automatically generated with MVC2 could easily be changed to support my existing logic.
What happens when a user is identified by a an AuthCookie? Does MVC use the MembershipProvider then?
Am I overlooking something?
I have the same questions regarding RoleProvider.
Input is greatly appreciated.
With MVC it is simple to bypass the Membership and Role provider framework altogether. Sometimes it is easier to do this than to implement custom Membership/Role providers, in particular if your authn/authz model doesn't quite fit the mold of those providers.
First, you should realize that you don't need to write everything from scratch, you can use the core Forms authentication API, which can be used independently of the Membership/Role provider framework:
FormsAuthentication.SetAuthCookie -
Call this after user has been
authenticated, specify the user name
Request.IsAuthenticated - Returns
true if SetAuthCookie was called
HttpContext.Current.User.Identity.Name - Returns the user name specified in the call to SetAuthCookie
So here is what you do in MVC to bypass the Membership/Role provider:
Authentication: In your
controller, authenticate the user
using your custom logic.If
successful, call
FormsAuthentication.SetAuthCookie
with the user name.
Authorization: Create a custom
authorize attribute (deriving from
AuthorizeAttribute) . In the
AuthorizeCore override, implement
your custom authorization logic,
taking the user in
HttpContext.Current.User.Identity.Name
and the roles defined in the Roles
property of the AuthorizeAttribute base class.
Note you can also define properties on your custom
authorization attribute and use that in your authorization logic.
For example you can define a property representing roles as enumerated values
specific to your app, instead of using the Roles property which is just a string.
Affix your controllers and actions with your
custom authorize attribute,
instead of the default Authorize
attribute.
Although you most likely can do this without a custom membership provider, I'm not sure that you save that much effort. Until I read this blog post I thought implementing one was hard, but it's really not. Basically you do this:
Create a class that inherits System.Web.Security.MembershipProvider.
MembershipProvider is an abstract class, so you are readily shown what methods need to be implemented.
The names are pretty self explanatory, so you can probably more or less copy your existing logic.
You might end up doing more than you need with this approach - but on the other hand, anything you might want to use now or in the future that requires a membership provider will already have its needs met.
The source of the SQLMembershipProvider is available here http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx. Take that as a base.
It looks a bit much at first, but you only have to implement the methods you need.
Yes the AuthCookie is used. Yes its a good idea to use the MembershipProvider, because it is well known by other developers.
There are thinks I dont like about it: For example It is not possible to have a transaction that spans the creation of a user by the membershipsystem and some other data in your own datbase. But still it works well.
I know what are you saying already (baad idea), but please read first :)
I am developing ASP.NET MVC based app, which will require some specific features:
combination of "local" users and facebook connect login, but FB users will be "mirrored" to some kind of local representation, because there will be some statistics and other stuff needed to keep for both types
authorization will be 3-layered instead of asp.net standard 2 layers. By this i mean : User is in Group (m:n) and Group is in Role (m:n), instead of User is in role (m:n).
So, if i would want to use standard authentication/authhorization approach, i would have to:
implement custom Membership provider, and it wont be even "right", because it will utilize methods like AddUserToGroup and AssignRoleForGroup etc.
implement custom Principal/Identity for sake of accessing my own User objects
casting HttpContext.User to my object every time needed...
implement custom Role provider
custom mechanism of sessting AuthCookie (unique userId in userdata, cant rely on username with third-party FB users in system)
... (you surely can think of something else)
Well, i really dont like the idea of "bending" and replacing every part to get pretty messy solution in the end. So I think of implementing my own mechanism encapsulated in one place - lets call it AuthService.
AuthService will be thread-safe singleton
Instead of AuthCookie will be using standard Session object (i know sessions also use cookies, but i really dont see advantage of low-level storage (cookie) over session)
AuthService will provide AuthService.CurrentUser (of my own type), populated from session on beginning of every request (Application_AuthenticateRequest, I think)
AuthService will provide in one place all methods - ValidateUser, RolesForUser, IsInRole, Logout, etc.
So now.. why should I not do this this way ? :)
I think session is equally secure to AuthCookie (same risks for ticket and authcookie)..
I dont really look for "modularity" (plug-and-play role providers, membership providers, profile providers..) - I deal here with pretty specific stuff, I dont expect standard components to fit.. have "my approach" any other disadvantages ?
Thanks for all good ideas and sorry my terrible english, I am from non-english-speaking country :)
R.
I can certainly see why you don't want to implement an entire Membership provider. However, I would take advantage of the low-level support offered by Forms Authentication (e.g. the cookie, expiration etc.) and just do my own custom authentication. If you do this, you can inject your own custom user class into the HTTP context and use it throughout your code. Your custom user object would implement IIdentity and IPrincipal. Your IPrincipal.IsInRole would work against your custom authentication scheme. This would allow your higher level code to use standard .NET framework permissions stuff. This is the neatest, simplest way to accomplish what you want while taking advantage of what already exists.
I'm creating a custom authentication service (I just need more than the default allows). I can't decide if I should extend MembershipUser and implement the appropriate interfaces, or completely roll my own. Is there any advantaged to rolling my own, or any pitfalls I should be aware of when extending the default mechanism?
How far from defaults are you?
If your needs are far apart from what MembershipProvider gives you, I suggest you go with your own. I personally haven't come across an application that connected to an existing data store. So we would be adding another application to it. Hence I find MembershipProvider way over engineered. Authentication/Authorisation usually also doesn't take too much time to develop and you control it completely. If it does take a lot of time it's probably also far from what MembershipProvider gives you.
But if your requirements are close to MembershipProvider, then you should consider it. Either as it is or derive from it on your own. But beware. This may take more time than delivering your own, because you will have to learn it through and through.
Security management requirements
If you go with MembershipProvider (or your own inherited class) you also get IIS integration so it's easy to manage security settings of your application. If you roll your own, you'll have to provide an interface for that as well which may take a considerable amount of time.
Implement MembershipProvider abstract class. I have an implementation with XML as datastore right here, if you need it.
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx?queryresult=true
Its always good fun to write your own provider but it depends on the security needs of the application you are building.
Most occasions when I have had to implement my own provider.
Using an orm such as nhibernate.
No database so requried to use flat xml files.
I had to build a system that required a more extensive role-permission system than the membership classes provided.
Good thing is you can switch between different providers if you need too..