In a previous post, I shared a baffling enforce version presence & language fallback issue, that lead my team down a rabbit hole until we discovered that it was indeed a critical Sitecore.Kernel bug that impacted all versions, including the recent 10.0 version.
Since then, the Sitecore product team has provided a fix for this issue, which will be part of the upcoming 10.1 release.
Until then, you can open a support ticket and reference bug #416301 and request help with your specific Sitecore version if you run into this problem.
How was it fixed?
As previously mentioned, the piece of code responsible for the permission denied error was within the GetAncestorAccess within the Sitecore.Security.AccessControl.ItemAuthorizationHelper class which is part of the Sitecore.Kernel.
Within this method, regardless of the value that was being returned for the security checks, the key/value combo was stored in AccessResultCache and resulted in the permission denied error being thrown the next time the item was requested for a different language.
To correct this problem, a EnforceVersionPresenceDisabler "using statement wrapper" was added within the GetAccess method that is responsible for returning the "access allowed for an operation on an item". See line 26 below.
The switcher disables the Enforce Version Presence functionality, more specifically, it bypasses the functionality that enforces the relevant translated language version of the item to be be available for it to be returned from the API.
This was the key in corrected the access issue related to the extranet\anonymous user, and enforce version presence logic.
0 comments:
Post a Comment