Does SimpleMembershipProvider use ApplicationName in anyway? I don't see any tables that will help it link in the documentation. I don't see any tables generated or linked in the actual source code itself,
GitHub - ASP-NET-MVC/aspnetwebstack
But isn't membership inherently bound to an ApplicationName? Or is there any workaround I can use to get this associated with. Basically I have an application and an admin portal, I want to use the same tables, but use different applications to identify different users and roles.
Thanks,
Fahad
You can use custom UserProfile table for storing such information. There is a very good information on asp.net blog: Customize the SimpleMembership in ASP.NET MVC 4.0
You may also consider migrate your project to MVC 5 and use OWIN authentication
No they moved away from the idea of partitioning users by ApplicationName (it seems a strange use case).
The preferred way would now be to just specify different connection strings and use separate databases (this assumes you have multiple apps).
If you want to partition users within a single application, you would ideally have 2 providers and direct calls accordingly, but SimpleMembershipProvider doesn't support non-default providers so you can only use one. You can overcome this, take a look at BetterMembership.Net, this supports multiple instances of SimpleMembershipProvider from a single application.
Related
I'm building a custom ASP.NET Membership provider since I'd like to use my own 'User' table for creating members and that kind of stuff. Here's the situation:
I've got a MVC 4 project that refers to a 'Services' project containing the service layer.
I built a wrapper around the custom MembershipProvider which helps unit testing. This wrapper references the custom MembershipProvider.
I reference the wrapper from my service layer.
I placed the custom MembershipProvider inside the MVC4 project (in the App_Data folder) because that's required as far as I know... At least: Visual Studio whines that it can't find the membership provider if I put it elsewhere.
So now I've got a circular dependency: MVC4 -> Service Layer -> Wrapper -> MVC4. My question: how do I get rid of that? Ideally I'd like to place the membership provider in a separate project, but I just don't get that to work. Any suggestions about that? Google isn't really helpful I'm afraid.
Bonus question 1: Should I extend SqlMembershipProvider instead of MembershipProvider?
Bonus question 2: Is there no better option? This whole ASP.NET membership feels really outdated and has many downsides imho (for instance: it isn't built to be testable).
You can absolutely put your custom membership provider in another project. I have two that I built as separate DLLs, and then added a reference in the web project.
You don't mention why you added a reference in your service layer, but if this is necessary you should really treat them as two different scopes, and therefore requiring two separate solutions. I have one membership provider that required calling a WCF service to authenticate membership, but those are two seperate pieces and you should not be sharing code between the two.
You do not need to place your code in the App_Data folder, just add a reference to your Membership Provider project or DLL in the web site project. Right
Bonus Question 1: No.
Bonus Question 2: The membership providers pre-date the whole TDD movement (as far as Microsoft is concerned), so yes, they are not real conducive to testing. But, if you inherit from the base classes, you are hooking into a well tested and time-worn framework, so you really only need to test your custom bits.
I use ASP.NET MVC 3 for an application which makes heavy use or Users and Roles.
To create a user and assign role(s) I use the standard process via ASP.NET Membership.
Throughout the entire app I use NHibernate for the underlying data access except the places were the default MembershipProvider and RoleProvider implementations are used (inside the AccountController which delegates calls to those implementations).
I would like to use NHibernate in order to be able to read/edit/modify the values on that tables which are managed by ASP.NET Membership.
I found two solutions:
Write a custom NHibernate implementation for MembershipProvider and RoleProvider (or even use this one). That's the hardest path.
Map only the tables (as described here) and then use NHibernate directly (although any default actions from AccountController will still handled by the default providers).
Any suggestions/recommendations?
I've used the custom provider you link with pretty good success. I did make a few changes to it, so that it would use a single session for its lifetime.
If you want to use ASP.net membership I think that approach is your best bet, mainly for portability (it doesn't rely on any SP's being present in your database). I'm currently using the modified provider from that link against MSSQL and Postgres with no problems, and I've used it against MySQL as well.
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.
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.
Setup:
Multiple web servers with synchronized
forms authentication.
Multiple asp.net Applications running on these severs.
What's working:
SSO across all servers
Authorization using asp.net roles
What's not so good:
All roles are "global" - I have "admin-app1" and "admin-app2" etc.
Question:
I know this can be solved by defining different "ApplicationNames" for each of the different applications but what is the most easy way to compile a list of all the different applications a logged on user has a role in?
I would like to do something similar to: CurrentUser.Applications()
to get a list of "all applications in which the current user has any role".
Up to now I have used Roles.GetRolesForUser() to compile the list not very elegant or scalable.
Using the SqlRoleProvider I can hack inte the DB to get the complete list of Applications and then compile an application list for the user by query the different application's role providers. My best shot so far but it doesn't feel like the best solution...
Any hints or comments?
BR, Jens
I have come to the conclusion that this cannot be done using the framework.
Anyone who tries to do something similar e.g. buiding a dashboard of all asp.net applications hosted has either to maintain the list of applications separately or hack into the sql tables if you are using the SqlRoleProvider .
Happy hacking!
/Jens
I think ApplicationName is for completely separating applications while using the same database. Are you sure you can link users in one application name to roles in another?
Your best bet is probably to keep the same application name and implement a custom role provider.
http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx