I am creating a sort of intranet system in ASP.NET that requires me to hide/show/disable/enable certain things depending on the logged on user's role. So far I have been using ASP.NET Membership (what I learned in school) however I am running into problems with having to customize things. We need usernames and passwords but we also need to add custom fields like first name, last name, clearance level (which will be used to set the user's role when they are added) and some arbitrary descriptive fields like employee title and office location.
We're using Microsoft Access (OleDB Connection in ASP) for the bulk of our database needs and we have an employee table that stores all the info we need (like names and clearance levels). I wanted to find a way to link records in those tables to the user that was set up through ASP. We need to be able to create, edit and delete users not through the web configuration tool but through the site we're creating (it will be managed by someone not familiar with ASP). Since ASP Membership uses SQL Server, it is becoming complex for me to try and find a way to connect the user tables generated by ASP and the employee tables created for the project.
I have now read online that there are two other versions of this kind of Membership system: SimpleMembership and Identity. Just by habit I'm leaning towards the most recent iteration (Identity), however I am now reading it is harder to query the user tables for appropriate role info and such.
Which would be the best for a system that has 3 specific roles and must disable/hide specific things depending on the role? And which one would be best for allowing me to create my own Add/Edit/Delete pages for users within the system?
MembershipProvider is depricated and replaced by Asp.Net Identity. Use Identity if this is a new project. Think of migration from MembershipProvider to Identity if it is a brown-field project, but it can take a week of time.
Identity is highly customisable and it is easy to add extra fields on a user and CRUD for users is very easy, especially if you know Entity Framework.
Related
I find a few topics on this, but they point to too-generic documentation or, for the link that seemed most pertinent so far, don't work.
(I'll refer to all the built-in functionality for membership/roles in .NET as "Membership" here on out.)
Using .NET 4.0 and Visual Web Developer 2010 Express and SQL Server 2005.
I'm creating a website where, in order to sign up, you need to be a paying member. I've already created the database that holds all membership info, and I've already created the form where they sign up, as well as the pages where they themselves or site admins can manage their account info. I've also even created a class for authenticating them and checking for permission on pages based on level of access (roles).
I'm hoping for a clear, concise explanation of either of these options:
• Point "Membership" at the place where username/password are stored, disallowing it from auto-creating its own db. (I'll then go back through my site and replace my own custom authentication in the few places I have it with official .NET "Membership".)
• Or still run my own custom authentication, but in that process, say to "Membership", "Hey! User known as "username" and of role "member" is now authenticated. Note that in your own special place, assign them that role, and know what to do with it when I ask you hereafter." Could this be "Forms Authentication API"?
There's more to the account than just username/password/role. I know I can add more fields to accounts created using .NET but I also really don't want to use some randomly created, self-contained, disjointed database just for the sake of handling logins.
I have not yet learned the basics of "Membership", though I'm getting darn close in my process of learning .NET; and I can't spend the time right now making progress on that for personal reasons, but I have to proceed with making this site. I would like to be able to use many of the benefits that come along with .NET security, like being able to exclude users from folders using web.config, etc.
Mostly I'm just seeking assurance it will be possible for me to backpedal after I get some other aspects of the project shored up, but before I make it live, and without having to rewrite half of the membership forms and splitting that data into several databases and figuring out how to use "Membership" for either pieces of it or all of it when a member signs up.
Possible?
If I understand you correctly, what you are working on is similar to something I am working on here.
We have a custom authentication scripts in ColdFusion and I am creating a second .NET System with Membership login.
The way I went about it was to move all the user/role/profile information into Membership's tables and created an additional tblUserProperties table which holds all other information that the Membership standard tables cannot hold.
I have recoded the ColdFusion queries to point to the new Membership tables.
This way, if a user change password from either system, the logins will work from the other system as well.
I think keeping two systems/tables that do the same thing (authentication) is risky because of the password change reasons. There could be more, but why can't you just simply change your custom code to point to where Membership is pointing? That way you can use Membership provider to its full potential.
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.
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 am trying to make an asp.net website using Visual web dev and C# that accesses data in an SQL database. For my site, I need to be able to save and access additional user properties such as age and gender. I have been playing around with the built in .NET Login tools but I don't understand how to keep track of the additional properties (age, gender...) I could store all the users information in my own database but how do I correlate the users data in my DB to the usernames in the member database that is automatically created?
Probably profiles are perfect and quite easy to use for your purpose. ASP.NET manages the relation between users and their associated profile data (which you can customize for your needs) quite comfortable. Here is short introduction video:
http://www.asp.net/learn/videos/video-44.aspx
Are you using an ASP.NET website project or web application project? The video (and most information in MSDN) is related to website projects. For web applications there are some complications to take into account when you use profiles.
(Some hints if you are using a web application project:
How to assign Profile values?
If you are using an website project you can ignore this)
As Slauma said ASP.Net Profiles is a great way to do this using the Membership API.
But I don't like the way profiles use delimited list serialized in the database, and I've heard reports of speed issues under heavy load.
I Use Membership API on just about all applications, except for the profile bit.
To store user profiles, you can create a separate table. Maybe called 'UserProfile'. Add a column with a unique index for 'username' and/or 'email'. Which ever you treat as the user's username. Now you can use that column to pull profile information at runtime.
As a bonus, if you use an ORM like Entity framework, you can now write simple LINQ queries to pull your user information.
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.