I have been using the ASP.NET Membership Provider System for the past 6 years, and have written several custom providers that are 100% compliant with the system. I have a client that would like to use Umbraco, but your implementation of the ASP.NET Membership Provider System is not compliant, which means that we can't use the built-in SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider, or any custom providers built on such. My question is, are there plans to either use the built-in providers or to write a provider that is 100% compliant and could be replaced by these? If so, what is the time frame?
My biggest concern is the statements made in the post at http://our.umbraco.org/forum/developers/extending-umbraco/2165-best-practice-for-membership-implementation. The statement "Nope, users and members are different concepts." is completely absurd and means that this person does not know how the ASP.NET Membership Provider System is supposed to work. There should be absolutely no difference between "users" and "members", other than the permissions (i.e. roles) that they are assigned to. Creating 2 different user lists is a very poor design and shows that there is no understanding of how the membership system works.
As it stands, it looks like I cannot recommend the use of Umbraco due to its security model, but we do feel that it has every other feature that is needed. I've tried removing all membership providers, using only the the built-in SQL membership providers, but it causes the IIS worker process to crash, which is very disturbing. The bottom line is, we need Umbraco to be 100% ASP.NET Membership Provider compliant, and to work with only the built-in SQL membership providers defined in the web.config.
Thanks, Bill Bosacker
P.S. Are there any plans to use the FCK Editor (recently renamed to CK Editor) instead of Tiny MCE?
Umbraco does use the MembershipProvider class model as of Umbraco v4. You can easily swap out the classes and put in the standard SQL membership provider/ role provider/ etc.
People have used the other standard .NET membership providers such as the AD provider with Umbraco.
With regards to your issue around Users and Members it seems like you don't understand the primary difference between the two. Users are only designed for the back office and Members are only designed from front office. It's true that you could combine them into a single membership store but that would raise a problem of cross polination. Users would appear in the Umbraco Members application and vice versa.
Like the Members you can swap out the Users for anything you want but it's not really recommended and not really supported. I'm not sure why you'd swap out Users for your own custom one though.
There is also no plans to use FCKEditor, TinyMCE works exactly as we need and it's a really great editor. If you want a FCKEditor then you can create your own Data Type which implements FCK. I'm not much of an FCK fan, I don't like it's UI and I will still add the missing letter to its name :P
I think that you have misunderstood what I said about the MembershipProvider. I said that it is not 100% compliant, which it is not. I did not say that it does not use the Membership Provider System. BTW, it is a system and not a single class. MembershipProvider is only one of several classes that are a part of the system. There are roles, profiles, and a few others as well. Is there any document that covers the complete replacement of the entire membership system (users, roles, and profiles) with the SQL providers? The identifier of the users in SqlMembershipProvider are Guids, not ints, which causes Umbraco to fail.
As far as the cross polination, that is something created by CMS developers who don't fully understand membership. The ASP.NET Membership System is designed to run autonomously in a database of its own, which may reside on a server that is thousands of miles away from the application server. Unfortunately, most developers don't consider this, or SSO, add it to the database of their application, and access the tables directly (which is an access violation). They should have a local user table that defines which users are "members" and which users are "users". If you need multiple sets of roles, you create a role table and map which roles apply to which type of user.
It is looking like most of the issues that I've run into are caused by the installation routines, which I'm trying to figure out. In them, user identifiers are hard coded to ints, in particular UserId 0(zero). FCKEditor would have been nice, but if it's not in the works we'll just have to stick with TinyMCE. BTW, these forums appear to be using the bugged version of TinyMCE which does not work well with IE. Since 99% of our users use IE, that is an issue.
After making some changes to ~/install/steps/defaultUser.ascx and the code behind, I was able to get the installer to work as long as I don't specify any packages to install, but I get a lot of missing page/control errors in the management window. The installer fails to use the Member.InUmbracoMemberMode() to detect if another provider is being used.
The Member class appears to work ok, but the User class is all screwed up and is hard coded to always use the [umbracoUser*] tables. That is proof that it will not work with any other membership provider. The stuff that I read about the AD provider is bogus as it is actually giving all users the settings of the "admin" user defined in the [umbracoUser] table. You can verify this by deleting the "admin" user from the [umbracoUser] table. If you are using any other provider, it should still work, but it doesn't. The application will crash and it will not allow anyone to log in.
Thanks for taking the time to explain the membership stuff and the results of your efforts. I'm not a core developer so I can't address the specifics of implementation details, but I can say that umbraco was designed before the membership provider was ever an option for umbraco. In the 'umbraco way', there is a huge separation between umbraco users and website members. Perhaps there could have been less separation but in the current umbraco architecture they are completely separate ideas, entities, and are thus implimented differently for their particular uses. This hasn't been a problem for users, though a few people have asked for some clarification to understand that it was by design, which it is.
For umbraco 5, which will be built on MVC, perhaps that architectural decision might be revisited. For now, however, users are in the umbracoUser* tables, as you've found, though the members can be stored in a membership provider or the built-in database.
I hope you'll find umbraco a solid solution for your needs as so many others have, even if you disagree with this architectural choice.
@Bill - You're correct that Membership in ASP.NET is broken up over several classes pertaining to their use within the system, but interchanging SQL memebership and Forms Authentication is as much a missnomer as SQL membership is just an implementation (but that's more semantics). As Doug pointed out Umbraco membership entered the CMS after the initial framework was developed.
In fact, it was until v4 that it acutally used the ASP.NET Membership classes for authentication, which is why there is the umbraco.providers assembly which really just wraps the User and Member classes from the cms assembly (at least I think that's where they are from).
You stated that using the SQL provider causes errors because it's GUID-based for unique identifiers, I'm not sure where this would be a problem, can you provide specific examples?
And you're definately correct that User is a mess. User is the only default Umbraco application section which isn't Node based which has caused it to be a real mess and there isn't a lot which can be done about it in the current architecture of Umbraco.
As Doug has mentioned Umbraco 5 will be an MVC build of Umbraco, so this will give us a chance to rethink how all the User/ Membership stuff is handled. We've actually already started discussing the User class, and due to the MVC nature of the CMS I can't see why we'd do anything other than having a better ASP.NET Membership implementation. I wont say whether we'd use SQL membership as the OOB implementation, we haven't started that much of an architectual discussion.
I've never had any complaints from clients using IE with TinyMCE but I'll admit I don't use IE myself on the forum or for my Umbraco editing. If you've got bugs with the forum there is a bug area which you should log them so the guys working on it can address them.
Thanks for the replies. Baring any other major issues than those above, and the fact the the entire site uses inline SQL (something that we will be changing for ourselves), it looks like we will be moving forward with Umbraco and YAF. I am sort of familiar with the history of Umbraco as it was on the list of unusable CMS applications, prior to version 4. If I remember correctly, the ASP.NET Membership System was introduced with version 1.1 and then later greatly expanded with version 2.0, but no one really understood it until 2.0, so I can understand why it wasn't used. In fact, 1.1 may have only been available to MSDN subscribers.
The issue that I found is in the installer, which only works if the Membership provider uses ints for the providerKey, as they are hard coded to 0 (zero) in the installer. I make the same mistake every so often when I forget that it must always be treated as an object, and instead hard code it to a Guid. After editing the files discussed above to use Member.InUmbracoMemberMode(), it was very easy to get the installer to work properly as I used the Username to access records as opposed to the key.
On a side note, for newbs, it would help if it was documented that the "umbracoDbDSN" and "umbracoConfigurationStatus" appSettings need to to be reset to their out-of-the-box states in order for the installer to execute. While trying to get Umbraco up and running, I had to start over several times. I had a bear of a time trying to figure out what kicked off the installer. I hope that the MVC version is going to be 100% ASP.NET Page/Master Page/User Control compatible, as that is a requirement as well. My fear is that MVC is going to be severely misused and incorrectly implemented, much like CSS has been for browsers.
I do have a framework that I have been building over the past 7 years, and will be releasing it as an open source project later this year. While we replace all of the inline SQL with stored procedures (a security requirement), we will be replacing all of the DB access code with this framework. If interested, we can make that available to the development team. As for the TinyMCE issue, it was fixed rather quickly after it was discovered, but it looks like the team is using the bugged version. Just open these forums in IE and look at this editing area, and you'll see what I mean.
I've been working on a project which includes an ASP.Net app and a newspaper which we want to do over a CMS, and we of course want it to be Umbraco. We've been learning how to do a good implementation of Membership Provider for the project since there will be a lot of services in the future and we want to unifie the authentication and authorization. Your comments gave us a light on what is going wrong when trying to direct Umbraco to our Membership provider.
I want to know if you finally find a workaround that you can share with us here. We are in the decisive stage.
ASP.NET Membership Provider System
To whom it may concern,
I have been using the ASP.NET Membership Provider System for the past 6 years, and have written several custom providers that are 100% compliant with the system. I have a client that would like to use Umbraco, but your implementation of the ASP.NET Membership Provider System is not compliant, which means that we can't use the built-in SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider, or any custom providers built on such. My question is, are there plans to either use the built-in providers or to write a provider that is 100% compliant and could be replaced by these? If so, what is the time frame?
My biggest concern is the statements made in the post at http://our.umbraco.org/forum/developers/extending-umbraco/2165-best-practice-for-membership-implementation. The statement "Nope, users and members are different concepts." is completely absurd and means that this person does not know how the ASP.NET Membership Provider System is supposed to work. There should be absolutely no difference between "users" and "members", other than the permissions (i.e. roles) that they are assigned to. Creating 2 different user lists is a very poor design and shows that there is no understanding of how the membership system works.
As it stands, it looks like I cannot recommend the use of Umbraco due to its security model, but we do feel that it has every other feature that is needed. I've tried removing all membership providers, using only the the built-in SQL membership providers, but it causes the IIS worker process to crash, which is very disturbing. The bottom line is, we need Umbraco to be 100% ASP.NET Membership Provider compliant, and to work with only the built-in SQL membership providers defined in the web.config.
Thanks,
Bill Bosacker
P.S. Are there any plans to use the FCK Editor (recently renamed to CK Editor) instead of Tiny MCE?
Umbraco does use the MembershipProvider class model as of Umbraco v4. You can easily swap out the classes and put in the standard SQL membership provider/ role provider/ etc.
People have used the other standard .NET membership providers such as the AD provider with Umbraco.
With regards to your issue around Users and Members it seems like you don't understand the primary difference between the two. Users are only designed for the back office and Members are only designed from front office. It's true that you could combine them into a single membership store but that would raise a problem of cross polination. Users would appear in the Umbraco Members application and vice versa.
Like the Members you can swap out the Users for anything you want but it's not really recommended and not really supported. I'm not sure why you'd swap out Users for your own custom one though.
There is also no plans to use FCKEditor, TinyMCE works exactly as we need and it's a really great editor. If you want a FCKEditor then you can create your own Data Type which implements FCK. I'm not much of an FCK fan, I don't like it's UI and I will still add the missing letter to its name :P
Hey slace,
I think that you have misunderstood what I said about the MembershipProvider. I said that it is not 100% compliant, which it is not. I did not say that it does not use the Membership Provider System. BTW, it is a system and not a single class. MembershipProvider is only one of several classes that are a part of the system. There are roles, profiles, and a few others as well. Is there any document that covers the complete replacement of the entire membership system (users, roles, and profiles) with the SQL providers? The identifier of the users in SqlMembershipProvider are Guids, not ints, which causes Umbraco to fail.
As far as the cross polination, that is something created by CMS developers who don't fully understand membership. The ASP.NET Membership System is designed to run autonomously in a database of its own, which may reside on a server that is thousands of miles away from the application server. Unfortunately, most developers don't consider this, or SSO, add it to the database of their application, and access the tables directly (which is an access violation). They should have a local user table that defines which users are "members" and which users are "users". If you need multiple sets of roles, you create a role table and map which roles apply to which type of user.
It is looking like most of the issues that I've run into are caused by the installation routines, which I'm trying to figure out. In them, user identifiers are hard coded to ints, in particular UserId 0(zero). FCKEditor would have been nice, but if it's not in the works we'll just have to stick with TinyMCE. BTW, these forums appear to be using the bugged version of TinyMCE which does not work well with IE. Since 99% of our users use IE, that is an issue.
Take it easy,
Bill
After making some changes to ~/install/steps/defaultUser.ascx and the code behind, I was able to get the installer to work as long as I don't specify any packages to install, but I get a lot of missing page/control errors in the management window. The installer fails to use the Member.InUmbracoMemberMode() to detect if another provider is being used.
The Member class appears to work ok, but the User class is all screwed up and is hard coded to always use the [umbracoUser*] tables. That is proof that it will not work with any other membership provider. The stuff that I read about the AD provider is bogus as it is actually giving all users the settings of the "admin" user defined in the [umbracoUser] table. You can verify this by deleting the "admin" user from the [umbracoUser] table. If you are using any other provider, it should still work, but it doesn't. The application will crash and it will not allow anyone to log in.
Hi, Bill,
Thanks for taking the time to explain the membership stuff and the results of your efforts. I'm not a core developer so I can't address the specifics of implementation details, but I can say that umbraco was designed before the membership provider was ever an option for umbraco. In the 'umbraco way', there is a huge separation between umbraco users and website members. Perhaps there could have been less separation but in the current umbraco architecture they are completely separate ideas, entities, and are thus implimented differently for their particular uses. This hasn't been a problem for users, though a few people have asked for some clarification to understand that it was by design, which it is.
For umbraco 5, which will be built on MVC, perhaps that architectural decision might be revisited. For now, however, users are in the umbracoUser* tables, as you've found, though the members can be stored in a membership provider or the built-in database.
I hope you'll find umbraco a solid solution for your needs as so many others have, even if you disagree with this architectural choice.
cheers,
doug.
@Bill - You're correct that Membership in ASP.NET is broken up over several classes pertaining to their use within the system, but interchanging SQL memebership and Forms Authentication is as much a missnomer as SQL membership is just an implementation (but that's more semantics). As Doug pointed out Umbraco membership entered the CMS after the initial framework was developed.
In fact, it was until v4 that it acutally used the ASP.NET Membership classes for authentication, which is why there is the umbraco.providers assembly which really just wraps the User and Member classes from the cms assembly (at least I think that's where they are from).
You stated that using the SQL provider causes errors because it's GUID-based for unique identifiers, I'm not sure where this would be a problem, can you provide specific examples?
And you're definately correct that User is a mess. User is the only default Umbraco application section which isn't Node based which has caused it to be a real mess and there isn't a lot which can be done about it in the current architecture of Umbraco.
As Doug has mentioned Umbraco 5 will be an MVC build of Umbraco, so this will give us a chance to rethink how all the User/ Membership stuff is handled. We've actually already started discussing the User class, and due to the MVC nature of the CMS I can't see why we'd do anything other than having a better ASP.NET Membership implementation. I wont say whether we'd use SQL membership as the OOB implementation, we haven't started that much of an architectual discussion.
I've never had any complaints from clients using IE with TinyMCE but I'll admit I don't use IE myself on the forum or for my Umbraco editing. If you've got bugs with the forum there is a bug area which you should log them so the guys working on it can address them.
Hey Guys,
Thanks for the replies. Baring any other major issues than those above, and the fact the the entire site uses inline SQL (something that we will be changing for ourselves), it looks like we will be moving forward with Umbraco and YAF. I am sort of familiar with the history of Umbraco as it was on the list of unusable CMS applications, prior to version 4. If I remember correctly, the ASP.NET Membership System was introduced with version 1.1 and then later greatly expanded with version 2.0, but no one really understood it until 2.0, so I can understand why it wasn't used. In fact, 1.1 may have only been available to MSDN subscribers.
The issue that I found is in the installer, which only works if the Membership provider uses ints for the providerKey, as they are hard coded to 0 (zero) in the installer. I make the same mistake every so often when I forget that it must always be treated as an object, and instead hard code it to a Guid. After editing the files discussed above to use Member.InUmbracoMemberMode(), it was very easy to get the installer to work properly as I used the Username to access records as opposed to the key.
On a side note, for newbs, it would help if it was documented that the "umbracoDbDSN" and "umbracoConfigurationStatus" appSettings need to to be reset to their out-of-the-box states in order for the installer to execute. While trying to get Umbraco up and running, I had to start over several times. I had a bear of a time trying to figure out what kicked off the installer. I hope that the MVC version is going to be 100% ASP.NET Page/Master Page/User Control compatible, as that is a requirement as well. My fear is that MVC is going to be severely misused and incorrectly implemented, much like CSS has been for browsers.
I do have a framework that I have been building over the past 7 years, and will be releasing it as an open source project later this year. While we replace all of the inline SQL with stored procedures (a security requirement), we will be replacing all of the DB access code with this framework. If interested, we can make that available to the development team. As for the TinyMCE issue, it was fixed rather quickly after it was discovered, but it looks like the team is using the bugged version. Just open these forums in IE and look at this editing area, and you'll see what I mean.
Take it easy,
Bill
Hi Bill
I've been working on a project which includes an ASP.Net app and a newspaper which we want to do over a CMS, and we of course want it to be Umbraco. We've been learning how to do a good implementation of Membership Provider for the project since there will be a lot of services in the future and we want to unifie the authentication and authorization. Your comments gave us a light on what is going wrong when trying to direct Umbraco to our Membership provider.
I want to know if you finally find a workaround that you can share with us here. We are in the decisive stage.
thank you very much
Frank
is working on a reply...