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.
Related
I have a question. I am looking at the newly implemented Simple Membership Provider and it suits my needs out of the box. I am however a little concerned about this provider as I am looking at creating a custom web application for myself and would like to know the security pros and cons of using it and if there is any best practices to go about building a secure web application. Is simple membership secure ? I am a noob when it comes to security.
I recommend not writing your own authentication and session management routines. Security is difficult and any flaws in your design or code could lead to exposure or breaches.
We have used Simple Membership in several web portals that handle PHI (protected health information). Our clients routinely audit our development methods and none so far have considered this a risk. Had we developed our own, they would raise a red flag.
You probably can get further by creating a library class of helper functions to add the features you feel are missing from existing providers, or subclass an existing provider (I don't think they are sealed/final).
In any case, your first step would be to draw up a list of features you want, check to see if an existing provider already does that (for example if you want an XML file provider, one exists on CodePlex), and if none do, either extend or write your own. If you write your own, you would want to make sure that there is another layer of security, like being on an intranet, or local access only or some other layer of defense.
I'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the Roles class.
The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.
Fairly new to ASP.NET's membership roles and forms authentication, it would seem that this would save more time and effort for my implementation.
But, I would also like to know if it comes in all goodness or does it carry any extra baggage (cons) in terms of:
Performance
Scalability
Thanks in advance for your replies.
I have never had a problem with performance or scalability with the default providers. Here are two tips that I've picked up along the way.
If you are using the providers and hashing passwords in a load-balanced setup. You will have to specify your machine key in the web.config
By default, users roles are not cached so every time you need to check a user role, you will make a round-trip to the DB. Using the cacheRolesInCookie="true" attribute in the tag in the web.config will cache them for you.
I've used the SQL Membership providers in ASP.Net in many large scale web applications and have never had any issue with it.
In our current application we've had to add extra fields and we expose these using an extra API.
Optimize ASP.NET Membership Stored Procedures for greater speed and scalability
Short answer: no real baggage in terms of performance and scalability. If anything, the real baggage is in terms of testability and portability (gobal static singletons are bad), but you can code around that.
It will probably work just fine, you can always switch provider or write your own later on.
I've written a provider that works as a layer between the ASP.NET authentication system and POCO classes together with a repository and nHibernate, that way I can let users login and get authenticated the ASP.NET MVC out-of-the-box-way, yet have the users and roles as any other model/view/controller in my system. Also by using IoC and interfaces I can use the exact same provider in different projects that handle users in different ways. Yay. Strange though that something like that didn't come out of the box.
If you use the default providers then it can be quite difficult to do things like search or filter users or do admin-type things, since you can't (easily) query the database directly. You have to go through the API, and it's quite limited. So, if you want to produce a lot of reports on users, be aware this is not easy to to efficiently.
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.