At this point in the development of our web application we are slowly finding the needs of the application to differ from what the membership provider offers by default. As we implement new features we are overloading the default methods and changing a lot of things to the point that it's getting confusing and the point of inheriting the MembershipProvider does not seem necessarry any longer.
My question is: besides the use of the custom controls like Login, CreateUserWizard (which we are already not using), RecoverPassword, etc. what is the benefit of using the MembershipProvider? I have already looked into such things as encrypting password and I feel that the Crypto helper class will provide that to us. What other things should I be aware of?
I cannot enumerate a list of things to be aware of off the top of my head, but I would encourage you to get rid of the MembershipProvider as soon as possible anyway. Don't invest any more time in bending it to suit your needs.
The MembershipProvider's architecture doesn't scale to the complexity of real-world applications and it is only really suited for 30 minute on-stage demonstrations.
Related
We are building a Form Builder (why reinvent the wheel and not use an existing one is not a discussion I want to have) for my company. Development is going well and I believe we have the right strategy for making it flexible enough and robust enough.
However, the problem lies in expectations. As project leader, it is my job to make sure expectations align with deliverable functionality, in fact project success depends on it, but I am having trouble defining what the form builder should be used for. I am concerned top management thinks of it as a one-size-fits-all solution, something I disagree with. I believe there are use cases for Form Builders and then there are use cases for explicit implementations, not all data should be stored in a dynamic form builder.
My question is: Is there a rule of thumb for determining what type of data should be implemented in a dynamic Form Builder and what should not? Or maybe not one but a set of rules.
For example, a purchase request might be a good fit for the form builder, but employee registration and attendance to company training sessions might not be since you'll most likely want to have that data readily available for querying and statistics.
Which types of forms should be implemented using dynamic form builders and which should have explicit static implementations in the database?
For my experience Forms builders are useful for specific cases. When you want to create interfaces for experience users to facilitate the management of data. When designing applications that are concern about the user’s experience, the form builders are all most the times not useful.
I've been trying to write an open-source profile provider to work against PostgreSQL (I was frustrated with the limitations and incompleteness in the other projects I'd seen available), but the documentation and examples of how people use it was surprisingly sparse. Even the SO tag for asp.net-profiles has a little over 100 questions associated.
The more I dig in to making it work, the less and less practical it seems; the value added does not seem to justify the complications associated; additionally, it only seems to work on a limited scope of web projects without a bunch of extra work.
I feel like I'm being led to the conclusion that it is not a popular technology, and that there are better ways to persist a more robust user-based information set.
Is my take on this fundamentally flawed? Is this widely used? I'm on the cusp of abandoning my profile provider as it seems to offer little of value.
I have always eschewed the ASP .NET Membership provider in favor of a custom implementation of IPrincipal for one simple reason. I've almost never needed the out-of-the-box functionality it provides.
Any custom implementation means creating your own implementation of MembershipProvider. Amongst other methods that I have never implemented, it includes wonders like RequiresQuestionAndAnswer and MaxInvalidPasswordAttempts. It forces an implementation upon you that you might not need and will take you more time to complete properly.
Sure, you could cheat and put a NotImplementedException in methods that you're not particularly bothered about, but what right-minded coder would feel comfortable with that in a production system? :D
I really like a lot of Microsoft's stuff, but my experience is that a lot of their "out-of-the-box" solutions are fine in vanilla mode, but the wheels tend to come off when you travel off the beaten path. A bit of cherry-picking is therefore required. My advice? Leave this one on the vine.
No, the Profile system in asp.net is not widely used, primarily because of the reasons you mention. It's just not useful for a lot of people.
The easiest solution is to simply create a profile table in your app, then key it on the ProviderUserkey of the Membership system.
Because the RoleProvider interface seems to treat roles as nothing more than simple strings, I'm wondering if there is any non-hacky way to apply an optional value for a role on a per-user basis.
Our current login management system implements roles as key-value pairs, where the value part is optional and usually used to clarify or limit the permissions granted by a role.
For example, a role 'editor' might contain a user 'barry', but for 'barry' it will have an optional value 'raptors', which the system would interpret to mean that Barry can only edit articles filed under the 'raptors' category.
I have seen elsewhere a suggestion to simply create additional delimited roles, such as 'editor.raptors' or somesuch. That's not really going to be ideal because it would bloat the number of roles greatly, and I can tell it's going to be a very hard sell to replace our current implementation (which is also very less than ideal, but has the advantage of being custom made to work with our user database).
I can tell already that the concatenation method mentioned above is going to involve a lot of tedious string-splitting and partial matching.
Is there a better way?
EDIT: My initial goal was to use more built-in ASP.NET functionality. For instance, control access via <authorization/> elements in the Web.config. Doing this, as far as I can see, requires implementing roles themselves. Our current system's concept of auths seemed to fit very well apart from that one limitation.
Answering mnemosyn's questions
Yes. We have a central database for users, applications and their authorisations. It's a core system and there's no going around it.
Currently our system is not hierarchical, and it actually takes quite a lot of effort to maintain. When an application is created, a set of authorisations are defined (e.g., 'admin', 'user', 'poweruser', 'gatekeeper', 'keymaster', etc.). Users are then associated with those authorisations with the optional value for a unique combination of user and (app-specific) authorisation.
Can you elaborate on these 'categories' of which you speak?
This really sounds like an architectural issue to me.
First, you need to determine what you need, exactly. In a second step, map this to a concrete implementation. To jump ahead on that one: I wouldn't use the built-in providers for anything but the most simplistic cases. Also, this problem quickly gets very complicated, so I'd try to keep it as simple as possible.
To elaborate your needs, try to determine:
Do you really need to map the role concept to the database, as you would in a CMS? Or do changes to your role system imply a modification to the system. In that case, you could go for a much simpler solution and put an enum into the user. This will save a lot of database accesses, makes joins simple selects, etc.
What are you trying to achieve through the multi-role concept you explained? Is it really roles that you need? How about individual permissions? Do you, for instance, have a hierarchical structure so that every node can have a certain set of permissions associated with it, much like windows' file security concept?
If it's only categories, why not map categories to users, i.e. give each user a certain role in each category. This will require some tweaks for default category, etc.
A few tips there: Don't go for whitelists, always use blacklists. Controlling whitelists is a pain, esp. when a lot of rules come together. In drupal, for example, I think this is one of the major flaws (which is why they're rebuilding it to use blacklists in version 7). Allowing a user to do something they shouldn't is usually a much bigger issue than the other way around.
The windows file access concept is very complicated, because it has both black- and whitelisting, which additionally can be inherited - so try to keep your solution much simpler than that.
The string concatenation thingie sounds rather dangerous to me, I'd go for a cleaner solution in any case. This type of meta-logic gives headache.
I am working on maintaining an ASP.NET website, and I've noticed the business layer and other supporting libraries make heavy use of HttpContext.Current.Session. This makes it hard to keep track of session variables, to determine what they're used for and why they even exist.
Is it considered bad practice to use the session in the business layer? And would it be wise to start moving all code that uses the session into the code-behind?
It's almost never a good idea. There's lots of reasons, but here's a couple:
you'll never be able to use business layer code in anything other than ASP.NET
Unit Testing becomes much more of a pain or even impossible.
We ran into huge headaches with this exact same situation when we started to build services that utilized common business layer code.
I follow this rule - any class in System.Web namespace (javax.servlet package in Java) should not be present in your business layer.
Yes - the BL should not have any knowledge about the Session. Its a dependency that you don't need.
make a class that is an indirection, in which case on the web it may return values from HttpContext.Current.Session, and in other areas would resolve that from somewhere else. IE have an interface ISessionStore and have concrete classes WebSessionStore and WindowsFormsSessionStore, etc.
this will make your code easier to test and also gives you expansion paths when say, you now want x business logic to run in a windows service where it can run x piece of code every y minutes.
In my opinion it is bad practice.
It makes it pretty hard to dissociate that business layer from the environment. If you expect to unit test the thing for example, you're out of luck.
One way to take care of that simply would be to insulate this into an abstraction for now, so that you can pass a "state cache" around and not refer to HttpContext. That will take you at least to some degree of abstraction.
Another more interesting question is, why does the business layer need to refer to that?
its always better to have a centralized Cache/Session manager which encapsulates the complete interaction with session/cache or whatever persistence method you use. having your BL to interact with sessions is definitely a very bad practice and in a way defeats the purpose of the tiered architecture altogether.
I have started design of a ColdFusion application that is entirely web based. Not much use of Flash forms, or AJAX.
The first version is a strict web app. Version 2 will be a Flex front end.
I want to design and build things so that the Flex layer can use existing logic. It's okay if it means I have to do extra work in version 1. I would like to harden the logic code once and not re-factor.
What are things worth considering / designing / implementing now that would greatly aid in being able to design an app in this way?
One big suggestion, depending on where you're coming from (as it's a rather big question), would be to leverage the ColdFusion component (CFC) as much as possible; the CFC architecture is excellent, versatile and powerful, it integrates quite nicely with Flex (and will do so even better in coming versions of Flex and CF), so to the extent you can design your component tier with that in mind, you'll be glad you did.
It's been a while since I wrote CF code, but on the last big project I did with it, I spent a good deal of time designing a functional tier out of CFCs to be used by the plain ol' Web app, much as it sounds like you're doing -- and then later, when it came time to bolt on an Ajax UI for a subsection of the site (it could've been Flex, but in my case, it happened to be a YUI implementation), I created a facade layer of publicly exposed CFCs whose job it was to wrap and expose a specialized subset of the functionality provided by the first tier. Doing so allowed me to leverage and extend existing code in a way unique to the services that needed it, without having to expose the underlying (first tier) CFCs directly.
I'm sure other folks will have many more (and probably more detailed) suggestions, but that's the one big one I have for you first off -- learn, know and use the CF component. Good luck!
I agree with Christian that the best thing you can do is put everything as far as database logic or any other logic for the application in CFC's, and more specifically, I would suggest using webservices. The main reason for this is that it will allow you to eventually have your cf code, which is all of your database persistence and logic on a different server than where you serve the flex applications from, and would allow code reuse for other applications as well. The nice thing too about writing your cfc's as webservices is that you can use them either as webservices or directly as components in Flex using AMF (remote object). Now of course how much those benefits really apply to you depends on your situation, but its a good plan to follow.
But the main suggestion is to think of your application as having a presentation layer and a logic and persistence layer. If you are making a decision, it goes in the logic layer. If you are showing a screen or doing anything with presentation, it goes in that layer. Keeping those things separate will allow you to more easily switch out your presentation layer to flex later on.
Also, it can be useful to trap any errors thrown and return messages as results (with any results, like in a structure) from all methods. Flex has a nasty habit of telling you something went wrong, but not passing along the error information. This will help you to debug and handle any errors that get thrown much easier.
Check out Matt Woodward's presentation on the topic, it's very informative:
And a few general things to add to the answers everyone else provided:
Encapsulate your data interaction in CFCs (typically in Services which delegate to Gateways and DAOs)
In most cases, you'll want to create "bean" CFC's to represent your business objects (users, widgets, etc), these are what will transfer to Flex as ActionScript classes. You'll need to add cfproperty tags to them to make them serializable to ActionScript (case- and order- sensitive!), so pay attention to that when you create them to prevent having to deal with it later, and use one of the code generation tools like the Adobe CF Extensions for Eclipse or Illudium PU36 to do it for you.
Create a remote facade CFC (or set of CFCs depending on how big the app is) that delegates methods to your Services - this is where you set the access for your methods to "remote" - generally the only place you want to do this (it will feel like you're doing a lot of delegating but it pays off to have all your remote services centralized)
As you develop with HTML, treat your remote facade CFCs as your API and make your HTML views as "dumb" as possible. Think of it this way: any logic you write in your CF view will have to be replicated in your Flex view. If you build the project only using your remote API, you'll have a pretty good feel for how Flex will interact with the application.
Check out ColdSpring, it offers a lot of great features for managing all the objects you're going to create!
I don't claim to be an architecture expert and I know I've thrown around a lot of jargon here to keep it short, but some Googling around CF blogs should turn up a lot of info about the design patterns I've mentioned. Good luck!