AI OnAI Off
Authorization issues in Commerce after upgrade R3=>7.5
Found out that EPiServer 7.5 is using another hashalgoritmtype, so this is added in 7.5 for the membershipprovider:
hashAlgorithmType="HMACSHA512"
We tried to remove it in both web.config for the website and in web.config for the Commerce Manager site, without any luck though, instead we tracked the Stored procedures when logging in, and found out that it is expecting another GUID than my user had, so we simply switched to that GUID for our user, after that the login worked for that user. And all users that we now create is working by default.
Jun 16, 2014 13:20
Hi,
That's quite strange because EPiServer Commerce have no intention to switch the hash algorithm - it might prevent users from logging in. In fact, the upgrading process to Commerce 7.5 will leave membership settings as-is. Do you have any custom membership provider prior to upgrading?
/Q
Jun 18, 2014 15:26
No we are running with the CMSMembershipProvider. From my knowledge though is that the HMACSHA512 hashalgorithm is new from EPiServer 7.5.
/J
Jun 18, 2014 17:43
Hi!
I'm having the same problem as you. Could you please explain in a bit more detail what steps you took to solve the problem. I dont quite understand which Guids you switched out, and what SP you are talking about.
Thanks for the support!
Jun 24, 2014 18:45
FYI, this is filed as a supportcase and we're working to resolve it. Hopefully we can deliver the fix in next iteration. You can also contact our developer support service to get update about this.
Regards.
/Q
Jun 24, 2014 19:44
I was directed to this post by Episerver Support and it is a integral part of my continued development and upgrading of my customers site to be able to view CM. If there is a way around the issue before a fix is released please advice.
Jun 24, 2014 19:46
FYI: http://geta.no/blogg/known-issues-after-episerver-commerce-7.5-upgrade/
Jun 25, 2014 9:20
Great, I was suspecting that there were other that was having the same issues.
Jun 25, 2014 12:34
Hi again.
We resolved the issue and here's the steps you want to apply to resolve this:
Fix:
To fix the issue, parters are advised to run those scripts:
- To add roles for accounts (mandatory):
insert into [dbo].[Security_RoleAssignment]
select newid(), c.ContactId, r.role, r.scope, r.CheckMode, r.IsOnlyForOwner
from dbo.cls_Contactc
inner join dbo.Security_RoleAssignment r on cast(substring(userid, 6, 100) as uniqueidentifier) = r.RoleParticipant
where c.UserId is not null and c.UserId like 'Guid:%'
and not exists (select RoleParticipant from dbo.Security_RoleAssignment sr where sr.RoleParticipant = c.ContactId AND sr.Role = r.Role )
- To delete old role assignment of user id.
This step is optional. The natural of "uniqueness" make it's very unlikely to have a UserId matches another ContactId. This is to make sure the old, invalid roles which map to UserId will be removed. :
delete from [dbo].[Security_RoleAssignment] where RoleParticipant in
(select cast(substring(c.userid, 6, 100) as uniqueidentifier)
from dbo.cls_Contact c
where c.UserId is not null and c.UserId like 'Guid:%')
It's strongly advised to backup the database before applying the fix. A restart of site might be needed to clear the cache.
We're considering including this fix for the upcoming nuget packages.
Regards.
/Q
Edited,
Jun 27, 2014 14:47
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
We've upgraded our Commerce R3 solution to 7.5, both EPiServer and Commerce upgrade scripts went without issues (well, the last time went without issues) and as well done neccessary codechanges and code compiles.
Now we are experiencing authorization issues. First we couldn't login at all (with correct user and password, and they exist in the Commerce db as well). Opened up episerver admin mode for anonymous users, and if we click "search users" we are getting the error: This request has probably been tampered with. So we thought it had something to do with the Anti forgery plugin but it didn't seem that way anyhow(tried to disable it).
When we changed from CMSMembershipProvider to WindowsProvider we could login in EPiServer and everything seemed to work correctly. As well we changed the password for the SQL users in the asp.net Web Site Administration Tool and now we could login in EPiServer (therefore I assume it couldn't verify the hashed password in the first place) and had full access with all roles, but the issue is that we can't authorize the users in Commerce, it seems that the roles in Commerce is in another table in the db, and everything seems correct with correct ApplicationID in the tables, the user got all roles as well in Commerce, but after login we are just getting the Unauthorized page, like the user doesn't have any roles at all. So obviously the script must have changed some mapping for the users so it won't recognize the roles, user gets authenticated(after changing password in asp.net tool), but not authorized.
Suggestions?