When testing this, it immediately looks like it works. When I add a member in the Members section of Umbraco, the member is added and shows up on the list. I am able to select and edit members as usual. The problem is that the search function always returns the complete list of members. This makes it really hard to find the desired member when having hundreds of members.
Another interesting thing that happens is that when creating a new member in Umbraco, the member is added to Umbraco's cmsMember table in addition to the chosen SQL membership table. This reinforces my impression that there is something wrong with how the SqlMembershipProvider works in Umbraco.
Using the SqlMembershipProvider worked better before upgrading Umbraco from 6 to 7. I'm not sure if the search worked in that version, but in v6 there was a list of all the letters from A-Z, making it easier to find the desired member:
Hi, Membership providers are not the sole source for all member data. They are used for the security part for membership. A standard practice for nearly all implementations in ASP.Net that use membership providers, is there is generally a 1:1 data association between a member in the membership provider and custom member data. Before version 7 there was no planned way to support having custom member data with a 1:1 association but from version 7 we started creating this implementation.
The 1:1 association I'm referring to is the CustomProviderWithUmbracoLink but unfortunately we never finished this implementation. You can see many references in our codebase for this to make it work but it was a very low priority because people have never really requested this and we are moving away from Membership Providers to ASP.Net Identity. But this is the reason you are seeing some member data existing in the cmsMembers table, it is there so that this CustomProviderWithUmbracoLink could eventually be enabled.
As for the search - this is a bug. The way this works is by directly querying the provider for paged results.
You can see the code for that here: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Editors/MemberController.cs#L104. However when a custom provider is used, the filter is not applied because it's still using the MembershipProvider's GetAllUsers method which does not support a filter. Instead, when a filter is applied, it would need to use the MembershipProvider's FindUsersByName or FindUsersByEmail methods.... unfortunately we can only pick one. So we'll use FindUsersByName and if there are no results we'll try FindUsersByEmail.
I can create an issue on the tracker and we can have this fixed in 7.4.3.
Membership providers actually work far better in 7.x+ than version 6. I realize the search thing is a bug but editing a member with a custom provider works tremendously better and actually adheres to the password and security rules specified, previous versions did not do this well.
it's worth mentioning the wildcard chars - SqlMembershipProvider users % as a wildcard char when searching whereas ActiveDirectoryMembershipProvider uses a *
Member search broken when using SqlMembershipProvider
I am trying to use SqlMembershipProvider instead of the default membership provider, using instructions I found on Stack Overflow: http://stackoverflow.com/questions/3046860/can-the-sqlmembershipprovider-be-used-with-umbraco/22290393#22290393 and Our: https://our.umbraco.org/wiki/how-tos/membership-providers/how-to-integrate-aspnet-membership-control-with-umbraco
When testing this, it immediately looks like it works. When I add a member in the Members section of Umbraco, the member is added and shows up on the list. I am able to select and edit members as usual. The problem is that the search function always returns the complete list of members. This makes it really hard to find the desired member when having hundreds of members.
Another interesting thing that happens is that when creating a new member in Umbraco, the member is added to Umbraco's cmsMember table in addition to the chosen SQL membership table. This reinforces my impression that there is something wrong with how the SqlMembershipProvider works in Umbraco.
Using the SqlMembershipProvider worked better before upgrading Umbraco from 6 to 7. I'm not sure if the search worked in that version, but in v6 there was a list of all the letters from A-Z, making it easier to find the desired member:
Hi, Membership providers are not the sole source for all member data. They are used for the security part for membership. A standard practice for nearly all implementations in ASP.Net that use membership providers, is there is generally a 1:1 data association between a member in the membership provider and custom member data. Before version 7 there was no planned way to support having custom member data with a 1:1 association but from version 7 we started creating this implementation.
For example, you can see we have this enum:
The 1:1 association I'm referring to is the
CustomProviderWithUmbracoLinkbut unfortunately we never finished this implementation. You can see many references in our codebase for this to make it work but it was a very low priority because people have never really requested this and we are moving away from Membership Providers to ASP.Net Identity. But this is the reason you are seeing some member data existing in the cmsMembers table, it is there so that thisCustomProviderWithUmbracoLinkcould eventually be enabled.As for the search - this is a bug. The way this works is by directly querying the provider for paged results. You can see the code for that here: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Editors/MemberController.cs#L104. However when a custom provider is used, the filter is not applied because it's still using the MembershipProvider's
GetAllUsersmethod which does not support a filter. Instead, when a filter is applied, it would need to use the MembershipProvider'sFindUsersByNameorFindUsersByEmailmethods.... unfortunately we can only pick one. So we'll use FindUsersByName and if there are no results we'll try FindUsersByEmail.I can create an issue on the tracker and we can have this fixed in 7.4.3.
Membership providers actually work far better in 7.x+ than version 6. I realize the search thing is a bug but editing a member with a custom provider works tremendously better and actually adheres to the password and security rules specified, previous versions did not do this well.
This is all done, you can see the notes here: http://issues.umbraco.org/issue/U4-8297
it's worth mentioning the wildcard chars - SqlMembershipProvider users % as a wildcard char when searching whereas ActiveDirectoryMembershipProvider uses a *
is working on a reply...