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
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 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.
I'm in early development stage of developing a web application. Im currently reviewing as to whether I should use ASP .NET Membership or write my own. Im more lenient towards to using ASP .NET Membership to save me some development time. Need help to clear up some ambiguities on how to best utilize membership database:
Membership creates a new database. Which one is better, to use the same database for my
application database OR creating a new database for my application? Why?
If I go for creating a new database for my application. Which one is better, creating a new user table in my application database or reusing/extending the user table in the membership database?
Thanks in advance,
RWendi
I myself am a fan of the Membership/Roles/Profile providers so I'm a bit biased. Basically if I were to evaluate what to use for a project I would look at the requirements. I can see no reason to implement your own membership functionality if the default works for you. It has many features and some pretty good optimizations (like columns with lowercase username and email for performance reasons).
I usually create a single database for my data and my membership. I link other tables by adding a username column but not a foreign key to avoid problems with deleting users. What is more the GUID that is the user id cannot be retrieved with the membership provider interface and you will need to write your own stored procedure if you want to reference stuff by user id.
On the question of separate database or not, separate tends to be the way to go if you have the resources (eg--you aren't on a shared host with a single sql server db). The main advantage is that the user data tends to be pretty application specific (eg--you don't need production user data in QA), so having it live separately makes things a bit cleaner as you only need to schlep about the application's data.
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