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.
Related
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.
I'm trying to understand the point of inheriting the Membership provider in a custom class and overriding it to implement your own custom provider.
What's the benefit of this when the Membership provider sucks in the first place!
I'm trying to figure out why people are inheriting from the provider when you can just roll your own. You're gonna have to create the logic anyway even if you override the membership provider classes. Plus if I'm gonna create my own provider I'm not necessarily going to want to model my method signatures or # of methods by this provider if I don't like it in the first place.
Yes, the built-in Membership provider sucks (I've had to re-write it myself, for use with large-scale sites where performance and scalability are concerns).
The advantage of using it is that it's easy, reasonably well documented, with lots of examples on the web.
The point of inheriting from the standard implementation is that makes it easy to just change the way a few things work. If you're going to re-write it from scratch, then I would skip the inheritance (which is what I've done).
You override the membership provider so that you can use the Membership API with it. This is useful for many purposes. For instance, if you're trying to integrate many third party web forums into your app, they require using the Membership API.
I fail to understand what people find so lacking in the membership API. Membership is not about having your users first and last names, or addresses or other information. It's strictly about validating login credentials, and providing role based security. That's it.
When you want to add other fields, you do so in your own tables, and make your membership ProviderUserKey a lookup value in your tables.
The main advantage is that the membership provider just works with all the "out of the box" asp.net features. Things like Forms Authentication, SiteMapProviders etc are designed to work well with the asp.net membership provider so often it's not so much the provider itself that is the key, it's the things that depend on the provider that make it worth while re-implementing.
Having said that, this doesn't mean that the membership provider will be a suitable fit for your situation, as you may not be using any of the components that are dependent on it, in which case, it doesn't make much sense to implement it and therefore you would be much better off writing your own membership model that does suit your needs.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I'm new to EF4 and haven't had any experience with it before. So, bear with me if this is very simple question.
I have my POCO entities (.tt file) in BOL, the .edmx file (EDM) in DAL and my webapp in Presentation layer. All the business logic goes to BLL layer.
Here are the references:
UI->BLL-DAL-BOL
BLL->DAL-BOL
DAL->BOL
BOL->None of my project.
1- Is my understanding of layers distinction correct? Am I in the right direction?
2- How can I use ASP.NET Membership provider with entities. Should I implement membership, persistence ignorant too and map all user tables in sql server to entities?
2- How can I add custom validation? I don't mean maxlength or valid email..., I mean something like access levels. For example I want certain users be able to modify a field (say productprice) in my website. Where should I use the User.IsInRole method? the BLL doesn't have any reference to user info. should I pass some parameters to BLL (like "bool CanChangePrice") to clarify access levels?
Wow Kamyar, just a few questions wrapped up in this one;-) I'm not sure if I'll cover all the possible ground, but here goes.
ProjectStructure
- generally your structure of projects is correct, and the references you have are correct. Some may argue that you want to separate your concerns a bit and break some of the references, but personally I find your structure workable.
As a practical matter I tend to keep my EDXM and POCOs in the same project. I just have an Entities folder that contains the EDXM and Model.Context.tt, a POCO folder for Model.tt and my Virtual POCO's (below), and a Repository folder for my repository & unit of work.
I also create a file called VirtualPOCOs which is a partial class bound to the POCOs generated by your T4's. My designs tend to be pretty tightly bound to database structure. The VirtualPOCO's give me a little flexibility to deviate from DB design in those one-off situations. Not to much goes in here, just those few very specific needs every project seems to have.
You may also want to consider a repository, table data gateway, or active record setup. All of these patterns will likely be combined with Unit of Work. There are tons of design patterns and your needs or preferences may push you to one or the other. The point here is to shield the upper layers from accessing the EF4 context directly. This way you can centralize connection & transaction management and ensure upper layers are only using POCOs and not accidentally holding on to linq-to-sql objects.
Membership Provider
There is a definitely a schism between the MembershipProvider and EF. You can, however, download the source code for the SQLMembershipProvider and convert it over to use EF. I actually did this conversion. The file is about 1500 lines long, but doesn't have a huge amount of ADO code.
What you didn't ask, but I think I should address, is whether you want to use Membership provider at all. If you're doing basic membership management and roles then the Membership, Roles, and Profile provider can save you a lot of time. For an in depth tour of the capabilities check out the series over at 4GuysFromRolla (https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx).
If your needs are more complex then, IMHO, the membership provider breaks down pretty quickly. For example, when a user registers for your site you immediately have to create rows in a handful of different tables. Well, the membership provider is registered through webconfig and uses the membership provider interface. It only accepts certain fields in the create function. So what's a boy to do? Well, you can open a larger scale transaction up in your controller, run the membership providers add user function, run your own MyCustomUserStuff(), then commit the transaction. Two reasons I find this unappealing are that I've now got transactional code seeping way up my call stack and if all I need to do is add a few extra fields I've now doubled my database calls needlessly.
I guess I just found the membership provider pretty restricting, and once got in there and made my own custom membership provider the benefits of using MS's model quickly fell away.
Validation
I think the answer here is a resounding --it depends. Are your permissions pretty static? i.e. those in the "SiteManagers" group can edit all over the site? Or are your permissions much more fine grained? Meaning SiteManagers have access to these 75 fields spread across these 22 tables, or is it more table based? Additionally, how mutable are the permissions ? Does your site admin need to be able to frequently turn access on/off or off to various fields in different tables?
I think I need to hear more on your requirements for a specific answer. Keep in mind that the more fine grained you make your permissions the more of a configuration headache the client will have understanding & managing all the permissions.
Also, what back-end are you using? Many DBA's face these decisions. One often used strategy in that world is to create a series of views where each view exposes the columns users have. For example, the EmployeesHR view would expose just those columns that HR people have access to, and the EmployeeDirectory would expose just those fields that the directory has access to.Then HR users are given permission to the HR view, but not the underlying table. Just a thought.
Anyway, hope this helps.
1- Your distinction of the layers seem correct to me.
I wouldn't reference the DAL in the UI, as in my projects, I prefer that only the middle layer access the DAL. But it's not wrong.
So you seem in the right direction.
2- To my knowledge there is no MembershipProvider that works with EF.
So in projects where we used Membership, here is what we did :
created the tables with the aspnet_regsql.exe
configure the Web.Config to use the SqlMembershiptProvider
added in the web.config ANOTHER connection string (one for Membership and one for EF)
Built the EDMX file with all tables, including the Membership ones.
In the code, a UserManager / RoleManager (BLL or DAL it depends on your architecture) get the informations using standard Membership methods. And always use the Membership objects, not EF ones. So in fact the user / roles management part is separated from the EF.
We only use the aspnet_* EF entities when there is a link between your custom tables and a Membership table (for instance, when you want to link one of your table with the aspnet_Users table to keep a reference of the user that inserted a data).
3- For the right management, I would use a BLL RightManager that would allow the UI to know if the user can change the field (so you can disable it, or prevent input), and to use this information in your validation method.
In my project I use a Right table and I associate a Right with a Role. In the RightManager provide a RequestRight(Right) method.
If your Right management is too simple to create tables, just use User.IsInRole() in your RightManager (so I would use it in BLL).
I would place the validation method in the UI if it is "basic" and in the BLL if it contains more complex rules (involving DAL access for instance).
about EF & Membership
as i know, you dont need to use any db provider instead of membership provider
but if you want, you can map membership tables in EF and create additional method to
common provider
I'm creating (really, re-creating) an app that has existing user and other data in MS-Access databases. The data will be moved to SQL Server, and part of that involves migrating users. I want to use EF to do ORM, and I am pretty sure I know what the data model will be in SQL Server. I am new to EF but not to ASP.NET, and I'd like to take advantage of the Membership features in ASP.NET. I am thinking about several ways to do this and would like some advice. I've done only a little research about this idea thus far, maybe it's been answered elsewhere. So, here goes a cluster of related questions.
Can EF work with directly with ASP.NET Membership through some class or namespace that I'm not aware of?
If I transition users to the Membership system, to align their userids with data in other tables should I create another set of tables for user data atop the aspnet_* tables a la DotNetNuke?
I want to avoid a situation where I use the built-in Membership functions for only user authentication and switch over to EF context when I'm working with user-tagged data. Seems clumsy to withdraw user info to bind to a column in a GridView by going into a Membership user for every row, but maybe that's what's needed? Do I need to suck it up and replicate the Membership classes in EF for data retrieval purposes?
I was thinking of maybe implementing some kind of EF provider for Membership, on the idea that maybe then the provider could sit inside the overall EF data model. Is this crazy talk? (I've never written my own provider before)
Feel free to tell me I am not making any sense.
Why not do it the other way around? You can implement your own Membership provider for asp.net, that uses the model you want/need.
If the features you need aren't a complete match with the built-in asp.net membership implementation, you can just roll your own provider. If you will use just a couple features, you will have to implement just a couple methods (you don't have to fill implementation for all the methods). If you need more features than it supports, using the membership provider might get in your way.
We do, but we don't map the Membership tables. You shouldn't presume use of the SQL membership provider.
We map the user identity, not the DB id. Subtle, but important. Again, remember that there are other membership providers (e.g., domain auth).
Can you clarify the question? You won't need to replicate all of membership info in your EF model, but you will need a list of known identities.
No, not at all crazy, but difficult and probably unnecessary.