I upgraded an 6.1.6 site to 6.2.1. I updated the membership and role providers to use the new providers. This all works and I can use the new MemberService (which is awesome!).
However, I did notice one potential anomaly. I can use the MemberService to create a new member that has an indentical username (login) to that of an existing member.
For example, this snippet of code runs fine, even though it creates 3 users with the same username (login) of "test":
for (int i = 0; i < 4; i++)
{
string email = "test" + i + "@example.com";
ApplicationContext.Services.MemberService.CreateMemberWithIdentity("test", email, "Test", "StandardMember");
}
I ensured the emails were the unqiue, as I know this can be configured in the provider to be true. However, out-of-the-box using default provider settings you can also create the 3 members with the same username and email address. This, to me, doesn't seem to be desirable (especially as there is a GetByUsername() method that only returns one member).
Here's some info of what is happening behind the scenes...
Previously with the old members api (I think) you could also create members with duplicate usernames.
In theory, the logic for creating members is done with the MembershipHelper, this ensures that all of the things that the MembershipProvider is responsible for are executed. The MembershipProvider is responsible for:
Dealing with duplicate entries like emails, since this is configurable at the membership provider level
Dealing with password security/formatting, since this is configurable at the membership provider level
The IMemberService is really just a way to interact with the persisted data.
You can see there's a unit test that tests for creating a user with a duplicate username here:
So the membership provider is dealing with this accordingly, but the check is not done at the Service level.
Moving forward, if we want to have the username uniqueness check applied at the Service level we'd need to agree that you would never want to store 2 member's who may be of a different member type with the same username... I'm not sure if people would use the functionality (probably not)? Or if there's anyone out that that really wants to have members with the same username... I agree with you that it doesn't seem right :)
I guess whichever way you go (allowing duplicates or not at the service level) then the API needs to be consistent. So if you can create multiple members with the same username then the service.GetByUsername() method should really return an IEnumerable<Member> rather than a single member. However, I really can't see this ever being desirable. So, personally, I would just go for ensuring usernames are unique - if this is what the provider does, anyway, then that makes sense.
However, its not a massive deal - as a developer creating users (say, via a registration) it is always wise to check usernames are unique anyway (you either check by seeing if a member already exists or you handle the exception that, presumably, the service layer would throw).
As far as creating members via registration, that is why the membership helper is there, it takes care of all of this for you, you don't want to be going direct to the IMemberService as that bypasses all of the stuff that the membership provider is responsible for. The membership helper takes care of quite a few underlying things like this.
I just ran into this today with a client not logging into their correct user info area in the website.
Reason: The site was pulling back the the first user found with the SAME user name.
They had renamed the "login name" in the CMS to the same user name inadvertently.
There should be some kind of check here in the CMS and a setting in the config to allow same user names or not. I do all the checks when registering etc but ive been back-doored by the CMS.
It would be great if you can do an upgrade locally to 7.3 to test if this issue still exists in that version. If it doesn't, then yes you will need to upgrade. If the issue still exists you'll need to log an issue with steps to reproduce and we'll have it solved in 7.3.1.
Should the new MemberService allow users to be created with the same username (login)?
I upgraded an 6.1.6 site to 6.2.1. I updated the membership and role providers to use the new providers. This all works and I can use the new MemberService (which is awesome!).
However, I did notice one potential anomaly. I can use the MemberService to create a new member that has an indentical username (login) to that of an existing member.
For example, this snippet of code runs fine, even though it creates 3 users with the same username (login) of "test":
for (int i = 0; i < 4; i++) { string email = "test" + i + "@example.com"; ApplicationContext.Services.MemberService.CreateMemberWithIdentity("test", email, "Test", "StandardMember"); }Here's some info of what is happening behind the scenes...
Previously with the old members api (I think) you could also create members with duplicate usernames.
In theory, the logic for creating members is done with the MembershipHelper, this ensures that all of the things that the MembershipProvider is responsible for are executed. The MembershipProvider is responsible for:
The IMemberService is really just a way to interact with the persisted data.
You can see there's a unit test that tests for creating a user with a duplicate username here:
https://github.com/umbraco/Umbraco-CMS/blob/7.1.5/src/Umbraco.Tests/Membership/UmbracoServiceMembershipProviderTests.cs#L41
So the membership provider is dealing with this accordingly, but the check is not done at the Service level.
Moving forward, if we want to have the username uniqueness check applied at the Service level we'd need to agree that you would never want to store 2 member's who may be of a different member type with the same username... I'm not sure if people would use the functionality (probably not)? Or if there's anyone out that that really wants to have members with the same username... I agree with you that it doesn't seem right :)
Let me know what you guys think!
Thanks, Shannon, that makes sense.
I guess whichever way you go (allowing duplicates or not at the service level) then the API needs to be consistent. So if you can create multiple members with the same username then the service.GetByUsername() method should really return an IEnumerable<Member> rather than a single member. However, I really can't see this ever being desirable. So, personally, I would just go for ensuring usernames are unique - if this is what the provider does, anyway, then that makes sense.
However, its not a massive deal - as a developer creating users (say, via a registration) it is always wise to check usernames are unique anyway (you either check by seeing if a member already exists or you handle the exception that, presumably, the service layer would throw).
Yup, I agree with all of that.
As far as creating members via registration, that is why the membership helper is there, it takes care of all of this for you, you don't want to be going direct to the IMemberService as that bypasses all of the stuff that the membership provider is responsible for. The membership helper takes care of quite a few underlying things like this.
Hi,
I just ran into this today with a client not logging into their correct user info area in the website. Reason: The site was pulling back the the first user found with the SAME user name. They had renamed the "login name" in the CMS to the same user name inadvertently. There should be some kind of check here in the CMS and a setting in the config to allow same user names or not. I do all the checks when registering etc but ive been back-doored by the CMS.
If you can replicate the issue with the latest Umbraco version (7.3) please let us know but i don't think that issue exists.
Hi Shannon,
OK. Unfortunatly the site is using :
Umbraco version 7.2.6 assembly: 1.0.5632.22681
Looks like i need to upgrade to fix this then?
cheers,
mark.
It would be great if you can do an upgrade locally to 7.3 to test if this issue still exists in that version. If it doesn't, then yes you will need to upgrade. If the issue still exists you'll need to log an issue with steps to reproduce and we'll have it solved in 7.3.1.
is working on a reply...