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.
Related
i have ASP.NET website with ASPNETDB.MDF database from default providor.
i have also MainDB.MDF that contains all other site database.
i want to combine ASPNETDB.MFD into MainDB.MDF in order to have only one DB.
is it possible?
if yes what are the disadvantages of this combination?
The only theoretical disadvantage is that you may want to run several apps with shared users. Then it would be better to have external provider. Most people don't do that of course then it is better to have data and users in the same database to make deployment and backup easier.
To achieve this just run the asp.net regsql tool against your database and it will create the tables. Then have just one connection string to your database and you are done.
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.
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.
Hai,
i am trying to store the user permissions for my web site.But I am little bit confused with xml and Database. For each user in site have different permissions. Have u ever faced this issue? for Example , if my site is a shopping site , for a local user , the report menu need not to display. A sales man need not to display the purchase page. and so on ..
I think you understood my problem .I have done this user management using a xml file . For each user a new node will create according to the menu and keep in the xml file . Next time the user login ,checks the permissions and and show only the allowed menus.
My boss tell me to do the same thing using the Database. by using XmlDataSource it is quite simple to bind data to the treeview (for setting permission) and binding to the menustrip also.
He is pointing the security problem . i don't think like so.
Which is better ? DB or XML
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
My advice would be to use asp.net membership and roles (written by Microsoft). It is a very good security solution - login security, roles (permissions) and is stored in a SQLServer database (not sure if it can be stored elsewhere).
I use it on my site and you can use membership controls straight out of the box (login forms, change password, etc.) or you can roll your own.
The only tricky bit I found was setting up the membership tables, views and stored procs in my dB (you download a dB script), but really it was fairly straightforward to implement.
Here's a link to asp.net membership and roles
ASP .NET Membership and Roles (part of the Provider Model introduced on ASP .NET 2) is (IMHO) nice only when you need some basic stuff. The issue is that you need to use the whole system using SQL Server, but if you are planning to move to a different DB provider (MySQL, SQLite, etc..) then you'd have to implement your own provider (which is at best painful), and learn how the whole pieces fit each other. Granted, finding a custom implementation it's quite easy, but is not a copy & paste thing.
Another bad thing of the default provider model is that you will get a ton of SQL stored procedures, also called maintainance nightmares. The issue is that if your site scales, then these SP's will make your life a living hell (been there) and if you even dare to change hostings then you're in for a treat, so my advice would be make your own permissions hierarchy and use it the way you wish. Also, look for advices and some pre-existing solutions to the permissions problem which is quite common.
Website security can be split up into to distinct parts.
Authentication: Logging in
Authroization: Roles/Permissions.
The ASP.NET Forms Authentication Provider is a great way to implement authentication. I recently created a custom provider that communicates with our companies X500 directory (LDAP). It was very straight forward.
For Authorization, we implemented the entlib security application block. It allows you to keep Roles/Permissions in a separate location that can be accessed by your UI as well as your service layers (assuming your developing a scale-able solution). You may also want to look at the Windows Itentity Foundation which is slated to supersede entlib security application block, however it is only available for .NET 4.0.
I'm pretty new into asp.net, and currently I have the need for storing various information in a database. Since I have used the standard Login control in asp.net, I already have the ASPNETDB database in my application.
My question is: Is it good practice to use this database for other things than user and role information?
Regards, Casper
Best practice would be to store the user/profile information in your normal SQL Database, therefore not using the ASPNETDB, but migrating all the tables and data to your application DB.