I was wondering if anyone could point me to some resources concerning customization of the user management system that is built in .NET. What I am talking about is: http://msdn.microsoft.com/en-us/library/ms998347.aspx
I would like to know, how can I extend the user fields to store more than just common password, username? I want to store for example: birthday, and other result sets.
In my opinion, you should not extend the membership tables at all. You should, instead, create your own tables and reference the membership data. One technique I use is to use the Membership GUID ID as a foriegn key to my own "users" table which contains my extended data.
This works out for the best because then if Microsoft decides to extend the Membership table in the future, your code doesn't break.
You are looking for Profile APIs http://msdn.microsoft.com/en-us/magazine/cc163724.aspx
This tutorial is very detailed on extending Membership API :
Microsoft ASP.NET 2.0 Membership API Extended
See:
ASP.NET Profile Properties
Overview
Defining ASP.NET Profile
Properties
Examining ASP.NET 2.0's Membership,
Roles, and Profile - Part 1
Related
What is the best and simplest way to extend the ASP.NET membership (add/delete/edit user functionalities) provided in ASP.NET. I'm looking to add a 1-2 columns in the aspnet_users tables. What do I have to do to make this happen. Editing and adding should edit these 2 extra user columns. Displaying the user should display these 2 extra columns. I'm new to ASP.NET Membership and I don't wanna write a ton of code?
You don't extend a membership provider itself: at least, not in this way. What you can and should do is rely on Membership just for authentication, and use the same userIDs from your provider as the primary key in a separate table/location to store any additional information about each user.
Under no circumstances should you roll your own authentication system.
ASP.NET Membership isn't easy to extend in the way you describe - the system is very prescriptive about schemas.
However, Microsoft did add in a possible solution: ASP.NET Profiles, which have an extendible field you can use for storing profile data. This is useful, however you can't run relational queries against these fields (as they're stored in a blob field in the actual database).
If you actually want to really change the nature of membership and authentication (and profile state) in your application then I'd give ASP.NET Membership a miss and roll everything by yourself.
I'm building a new Asp.Net MVC3 solution and would like to have all the tables in the same database (including membership, users and roles tables). So I don't want to have a separate aspnetdb.mdf file. I think I only have to adjust membership section in Web.config (connectionstring) in order to point to my unique database. Right? Please correct me if I'm wrong. So until now, no need to customize the membership provider.
Second question: can I name my table for managing users (membership) the way I want without customizing the membership provider or do I have to customize it? I think I have to customize the membership provider if I change the user table name. Correct?
Thanks.
You certainly doesn't have to implement your own provider (I mean you can if you want but I cannot see a reason).
I would create a blank database and then fill it in with the Membership database schema via aspnet_regsql.exe tool. Here is a great blog post on that:
Installing ASP.NET Membership services database in SQL Server Express 2008
Then, build your own tables, UDF, SP on that same database. You will end up with one databse at the end.
Point your membership provider to that database and you are good to go.
Description
It looks like you have to implement your own MembershipProvider and MembershipUser. That sounds harder than it is. You can implement your own logic, own data access and more. This i also i good thing to learn how ASP.NET handles authorization.
More Information
Implementing a Membership Provider
How to: Sample Membership Provider Implementation
I don't like asp.net profile provider store all profile info in one or two row in the database, but I want to use membership/profile API for authentication purpose.
Customize membership/role/profile provider requires big big upfront efforts, which may cause more mess later.
So how do people deal with that normally?
You don't have to use asp.net profiles to store additional information if you don't want to. Instead you can store it in a separate table and link it to aspnet_Users table like shown here: Storing additional information
You can use the built-in
SqlMembershipProvider, which is
installed by running
aspnet_regsql.exe.
You do not have to use profiles if
you don't like them.
Customizing membership/role/profile
providers is really not that big of
a deal.
I already got a table stored all customer information. Such as name, email phone, password and other things.
In this case, how can I take advantages of asp.net membership/role/profile provider?
I want to use annotation in MVC2 to do authentication and such.
Thanks for your advice, any reading URL is welcome.
You'll probably need to create custom membership provider.
Check out:
MSDN Article
ASP.Net Video
And see if they help you
There are very simple way
1. use aspnet_regsql.exe
(in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727)
Choose option add to existing database
Use your name, email, phone like Profile, or you can create script which add users automatically(and you need add to this user phone,email etc)
http://forums.asp.net/p/1540444/3753784.aspx
(It's useful documentation about asp.net roles,membership etc)
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
I'm throwing in a CW answer to compare/contrast the other two "real" answers.
So you have two choices: Use the standard membership provider and their database schema as per John's answer, or create your own membership provider and utilize your current database as per user517656's answer.
If you use the standard provider, you'll have to migrate your users into the microsoft database. But once you do that, you shouldn't have to write much code at all.
If you use a custom provider you have to write all of the code yourself, but you don't have to change your database.
With this question I am mostly looking for answers from people that have implemented the out-of-the-box ASP.NET membership in their own database - I've set up the tables inside my database and as far as I can see they contain mostly what I need but not everything. I will have the notion of a Firm (Company) to which Users will belong so I will have to associate the aspnet_Users with my Firms table (each user will be a member of exactly one firm).
If possible, provide some guidelines how did you do it and what I might run into if I have to modify the table design at some point in the future. Preferably I will be using the default Membership provider.
I am having trouble to decide whether to go from scratch or use what ASP.NET already offers.
I would suggest that you need to use a table-based Profile Provider implementation such as this one that Scott Guthrie blogged about. It is much better than the out-of-the-box profile provider as it allows you to define your own tables for profile information. In your case you would have a table that contains a Row per user and a FirmId and anything else you like such as nick name, social security number, whatever.
It works with the default Membership provider so you won't have to make any changes to it. There are two implementations in the example, a Stored Procedure based one and a Table based one. I prefer the second but they are both very easy to use.
The default profile provider proved a bit rubbish because it stored all of a user's information in a single field. The provider that I suggested solves this in a very efficient way.
I decided not to use ASP.NET Membership provider and its default tables because of the changes that might be introduced in future versions, so I eventually ended up using this custom Entity Framework provider by OmidID although I had to tweak it quite a lot. But I can now say that we have a rather fullproof entity framework based membership provider that we can easily maintain and indenpendent of the ASP.NET membership tables in SQL Server.
I would treat the ASP.NET membership as a separate service. Just use it as is and add any additional functionality on top of it.
In this case just create a table which links the users to the companies but don't alter the ASP.NET tables. If you have any additional information you need to store about users put this in another table which is associated with the ASP.NET membership users table.
Update: I've started using this ASP.NET MVC Area to administer users and roles https://github.com/TroyGoode/MembershipStarterKit. It comes with all the necessary models, views and controllers and is fully unit tested. Didn't take more than an hour to get it integrated into my site and up and running.