I am currently developing an web site using asp and have a few questions regarding Membership Provider.
I am currently inheriting from Membership Provider class and have just got over the issue of only certain parameters being able to be passed to the CreateUser method.
I have been able to overcome this issue by creating a class that inherits from MembershipUser adding custom properties and then passing that the the UpdateUser method. However to me this seems quite messy and not very efficient as I am making two calls to the database when I could do it in one if I dont use the CreateUserWizard.
So my question is, is using the Provided Login components worthwhile if you are overriding the methods and require more parameters ect in order to keep the use of the properties you can define for this class in the web.config file or is it easier in the long run to just start from scratch. Basically what I want to know is how people have found using Membership by overriding and inheritance over starting from scratch, and how these compare.
Any webpages that talk about this would be good and apologies if the question doesn't make sense or I have missed anything out.
Thanks,
Ric
If I am understanding your question correctly, then yes the membership provider is a great api to build off of so you don't have to reinvent the wheel for the basics of authentication/authorization.
You are using Membership wrong. You should only create your own custom provider when you need to map onto an existing database. IF you are making your own database, then you should just use the default implementation.
Even if you create a custom implementation, you should not do anything that the current membership doesn't already provide. Just map those functions on to your database.
To add additional information, you create a secondary table called UserData or something. This table will be keyed by the MembershipUser.ProviderUserKey, so you lookup any data you need from the other table using the userid from the membership class.
You're really fighting upstream trying to change membership to give you custom things. You can do it, but why cause yourself trouble?
Related
Will someone please tell me how to create a user without using membership.createuser() and create user wizard in asp.net? I need to perform an additional insert on an existing table during CreateUser().
Here are two ways to go:
Implement your own custom membership provider. This is easier than you think and pretty straight forward. There are plenty of articles around.
or
To save you some time... implement your own custom membership provider and inherit from the SqlMembershipProvider class. In the subclass you will mostly just "forward" the calls to the base class except for in the CreateUser method. In this case you can let the base class do most of the work and then perform your custom insert. However, since it does need to be in one transaction (per your comment above) then things might be a little hairy... and you would possibly have to reimplement the CreateUser method in your subclass.
http://msdn.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.aspx
Note: I am on a bus right now via Wifi, but I am almost tempted to write this for you if you include the emp_details schema for me. Are you using straight ADO.NET or something else?
I wrote a custom Membership Provider and it was relatively easy.
Now I need to create users with first name, last name and other fields not considered in the any of the MembershipProvider.CreateUser overloads.
I read that I should not overload CreateUser. Instead, I should write my own Profile Provider.
It seems like a lot of work and I am not sure of the benefits. Can you help me decide the right way to go? (It is for a MVC 3.0 web app.)
It depends. If it isn't a lot of info, you could just create a custom MembershipUser class with the appropriate additional fields. You can look at codeplex.com to find examples of custom Profile implementations.
I'm working on an ASP.NET solution with 2 projects. One is the web interface and the other contains my business logic. I'm using LINQ to SQL for my data access in the second project.
Apart of my database, I have a table called Users which holds user information.
I've started to implement a MembershipProvider. I notice that MembershipUser is coupled with MembershipProvider. What is the most correct way of getting my BLL/DAL to talk about Users?
Should I minimally implement MembershipUser and whenever a user calls a method, it will call for eg. GetUserInfo() in my BLL/DAL, to get complete information about the user?
Or should I make the MembershipUser class methods call my custom "Users" class methods (like a wrapper) in the BLL/DAL (this custom users class is not related to linq)?
Or can I somehow extend the Linq to sql class "CFUsers" to extend MembershipUser.
I hope this makes sense.
I usually see this a seperate entities as MembershipUser revolves around membership which is a generic concern and a user in your system revolves around whatever your domain entails, I do see your point of view where both these entities could be contained in one, so. Profiles is definitely the easiest way to go.
There's a walkthough on the MSDN docs at
http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx and a
good walkthrough from Scott Guthrie at
http://weblogs.asp.net/scottgu/archi...18/427754.aspx
As always It depends on what your goals are. Adding to Profile is a simple mechanism
for additional data. It requires very little in the way of customization and
makes the info easily available for the web application. This may not be
where you want to store this type of data; if not, it is a non-solution.
If this does not fit, making a new provider derived from the default (to
inherit what you already have) is a great option.
and of course the ultimate http://codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/
I'm looking into Asp.net Membership Providership Sql to determine if it fits my needs and have a few basic questions.
It seems to create a lot of tables, many of them I don't think I need. I only need one application and no role management. Can I remove the unused tables or should I just leave them alone?
I need another table where I can associate records with the users created with the Sql membership provider. Is it safe to use the "Membership.GetUser.ProviderUserKey.ToString()" as the primary key for this user. I guess so, but it feels a bit like I'm depending on something that's out of my control since it's Asp.Net that manage it.
Also I'm going to access the database directly, without logging in with a user to get statistics. Is it safe to make Sql queries against the database using the aspnet_Users.UserId (table.field).
I guess what I'm afraid of is that suddenly after an framework update, Asp.Net changes the table layout or something.
Obviously, you can do whatever you want to it once you've generated the tables, but I think you should consider the ramifications of that. The Membership Provider framework works very well and is widely implemented. If you use their implementation, just use it and use the pieces you want and leave the rest alone.
They will be very careful when/if they make changes to it to either tell us of the breaking changes or not make any breaking changes.
The framework allows for you to override many of the provided methods, or you can simply write you own custom provider and base it heavily on the out of the box implementation.
ProviderUserKey is meant to store anything you would need to reference, so you can store a key to a record in your own database to store additional user information. I think it's OK to delete unrelated tables, as long as the features you use don't touch it.
I know it touches aspnet_applications, aspnet_users...
As a last resort, you can always create your own custom membership provider by creating a class that inherits from MembershipProvider.
If I need to implement my own MembershipProvider class, I have to implement all the services I require myself, so what advantage do I gain by implementing a MembershipProvider derived class versus just writing my own MySecurity class?
Getting an authentication system right is hard, because it's so easy to build something that only appears to work. You don't want to find yourself in a situation where a year after deployment you finally discover your system was cracked six months previously.
Building your system using the MembershipProvider model helps you do it right by giving you a skeleton that lends itself to being implemented correctly. You only need to accurately fill in a set of methods, and you can rely on the high-level architecture provided to make sure you are using the right methods in the right places.
Getting individual method implementations done right is comparatively easy. You can put those into your unit test and have confidence that they do what they are supposed to.
Put another way, you don't have to worry about whether you check your authentication token in the right places. The parts of ASP.Net that call into the membership provider know when to do that. All you have to do is correctly implement the check, and that normally comes down to a simple comparison.
Additionally, you may not need to start from scratch. You have to option to inherit from an existing provider and only add the functionality you want that it doesn't already provide.
If you just need something a "little" different from one of the default membership providers then you should probably just consider inheriting from one of the built-in providers or one of the better 3rd party providers and extend it with the additional functionality that you need or override the functionality that you want to change.
The main advantage of writing your own MembershipProvider class is that it's considered by the ASP.NET as a first-class component and you can use the standard interfaces for authentication and authorization and only have to change the config file afterwards if you want to use a different provider.
Technically, you should gain some level of portability - by using the existing model, you should be able to drop your provider into other web applications, to replace their membership system with very little effort.
Unfortunately, the number of 3rd parties out there who seem to have gone their own way when it comes to membership/profiles is quite impressive, and also rather depressing, especailly when you've put all the effort into writing something based on it.
That being said, by using the membership provider model, all the other controls that use membership "just work" (i.e. Login, LoginStatus, LoginName, etc) without having to write custom versions of those as well.
Well, it depends... I found it very useful because I had to add the concept of functions, so that every role had functions associated to them, and so forth.
In that case I implemented my own Membership and RoleProvider classes which contained the AddFunctionToRole method... IsFunctionAssignedToUser method... etc etc
A little more info on that here