i want to use asp.net membership provider for my own database i have own table
here is what have i done
i extended the membership provider class with my own write all overided methords.
is it right way to use membership provider class for custom use?? i also extend the rolemanagement class too.
What's "right" and what's "wrong" is hazy, as different people have different opinions.
My opinion is that you should never extend the membership tables, because by doing so you create potential problems down the road if Microsoft decides to add additional functionality to those classes.
Instead, you should simply use the asp.net membership provider keys as foreign keys into your own tables. Thus, you might have your own "users" table, but one of the columns is the asp.net membership User ID value. This allows you to relate them together and get at that information, without extending the asp.net membership tables themselves.
I have tried implementing custom membership user, and succeeded after a month's effort. One idea I always have is, no one can ever generalize what our requirements should be, and especially a vendor should not decide in particular.
It is good we have a way to extend the membership user. This and that are the best resources to guide how to write a membership user.
Related
I'm relatively new to ASP.NET MVC, but I already did C# for a while and I already took the MVC basic course. What I'm stuck with is the "ASP.NET Membership".
For my website, I need a registration (with email, password, and some cstom fields), a login, "roles" (user, admin. moderator, etc...), "settings" (change password, etc ...) and cca. 40 custom fields (like date of birth, favorite color, car type, etc ...) connected to the user.
How should I make it in MVC?
I have found the SimpleMembership, but I don't need most of it's features, and the features I need are missing.
My time to shine!
I would recommend using the Entity Framework, because reasons. It makes DB interactions very simple and readable.
you can write your own membership provider in MVC, which like you said you wont need most of the features, so you dont need to implement them. This dude implemented it all here ->
http://www.brianlegg.com/post/2011/05/09/Implementing-your-own-RoleProvider-and-MembershipProvider-in-MVC-3.aspx
He tells which ones to focus on, and shows roles and authorization.
Essentially you will map a User model to your User table using the entity framework, then use that user model when the person is registering. You can even use validation attributes, as seen here->
http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validation-with-the-data-annotation-validators-cs
What other questions may I answer to help you on your journey today my good sir?
Personally, I like to use the built-in membership provider (have yet to look at the SimpleMembership) for the registration, login and roles.
I then simply create my own member tables that I tie together with the membership User table.
This simple approach prevents me from having to create my own membership provider, and I am free to define the member table the way I want.
I am looking at migrating an old app to MVC4 but can't yet modify the database. The existing database already has it's own user / group / membership tables setup (in a rather quirky way might I add, but it works).
With the MVC3 style MembershipProviders I could roll my own extending what I needed to login, check role permissions, modify user attributes etc. but I'm at a loss as to how to achieve this with MVC4 and it's SimpleMembership and then how to use OpenAuth alongside it as an alternate way to login.
I've been looking around but there seems to be very little content online yet regarding it, any ideas?
I don't require a SimpleMembership implementation, if anyone is aware of another similar provider that would do too.
SimpleMembership is just like its name: simple. So if you want to extend the membership provider to meet your complex requirement of roles and membership, it's not a good choice. If you do really have to upgrade your app to mvc4, just do it, then reuse the ASP.Net Membership that exited in your app. It's still running properly on mvc4.
One thing to try is to just use SimpleMembership and add as many roles as you need to make up for your current "attributes". Depends on what you mean by "attributes". If you just want to add additional columns to the UsersProfile table, it's pretty easy to do. And then the SimpleMembership API can access those new columns just as it does the built-in ones in a default MVC4 Internet App. project.
Have you viewed this SO thread?
what's the best?
use a profile table to store information that's not present in membership table (like country, age, etc.), or customize a membership?
thanks
Membership data should typically be comprised of information that relates to authentication. i.e. security.
Profile is typically the appropriate place to store user meta data. i.e. personalization.
These 2 types of data serve different purposes and the segregation enables a clean separation of concerns in the providers.
An exception to this could be considered if there is some non-standard meta data that directly relates to authentication/authorization.
Whenever possible, it is best to use the built in providers. This reduces the amount of code you have to design, implement, test and maintain. And Membership, i.e. security, is not something that you want to find bugs in.
So, I would consider using the tried, tested and true membership provider and if you want table based meta, use a custom profile provider such as http://www.asp.net/downloads/sandbox/table-profile-provider-samples
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.
I have an existing database with users and administrators in different tables.
I am rewriting an existing website in ASP.net and need to decide - should I merge the two tables into one users table and just have one provider, OR leave the tables separated and have two different providers.
Administrators, they need the ability to create, edit and delete users. I am thinking that the membership/profile provider way of editing users (i.e.
System.Web.Profile.ProfileBase pro = System.Web.Profile.ProfileBase.Create("User1");
pro.Initialize("User1", true);
txtEmail.Text = pro["SecondaryEmail"].ToString();
is the best way to edit users because the provider handles it? You cannot use this if you have two separate providers? (because they are both looking at different tables).
Or should I make a whole lot of methods to edit the users for the administrators?
UPDATE:
Making a custom membership provider look at both tables is fine, but then what about the profile provider? The profile provider GetPropertyValues and SetPropertyValues would be going on the same set of properties for users and admins.
Probably you should merge the two tables into one and use a RoleProvider to make the distinction between administrators and "normal" users.
Alternatively, you could implement your own, custom membership provider, which would use both tables.
Mike,
My advice is to go ahead and merge your two 'membership' tables and segregate admins from non with roles.
(This is, I know a duplicate of the previous answer but I feel the need to explain..)
In this way, unless you have some compelling reason to implement custom providers, you will be able to leverage the stock providers and database structure to provide a robust user management story for your website without writing any code (that you have to test and maintain).
.2 pesos....