Recently, to meet project requirements, we customized and expanded the functionality of the “General Link†feature by incorporating a new “Telephone Link†feature. Everything was working correctly on our local project instance, but we got the below-listed error when the changes were deployed on the higher environment.
Exception: Sitecore.Exceptions.AccessDeniedException
Message: Calling Fieldtypes.ExtendedGeneralLink.ExtendedGeneralLinkForm.OnModeChange method through reflection is not allowed.
Source: Sitecore.Kernel
at Sitecore.Reflection.MethodFilter.Filter[T](MethodInfo method)
at Sitecore.Shell.Framework.Commands.CommandManager.GetMethodCommand(String command)
at Sitecore.Web.UI.Sheer.ClientPage.Dispatch(String command)
at Sitecore.Web.UI.Sheer.ClientPage.RaiseEvent()
at Sitecore.Web.UI.Sheer.ClientPage.OnPreRender(EventArgs e)
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Solutions: Handling Not Allowed Reflection Method in Sitecore
I looked into the problem and discovered the solution provided by Himmat Singh Dulawat in this article. Since it was my first time implementing these required patch solutions, I wasn’t familiar with the proper patch file hierarchy or the pattern that needed to be added correctly. Below is the necessary configuration structure for adding the patch file.
<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration xmlns:role=”http://www.sitecore.net/xmlconfig/role/” xmlns:security=”http://www.sitecore.net/xmlconfig/security/” xmlns:patch=”http://www.sitecore.net/xmlconfig/”>
<sitecore>
<reflection>
<allowedMethods>
<!–For example: <descriptor type=”SampleNameSpace.MyClass” methodName=”MyMethod” assemblyName=”MyAssembly”/> –>
<!–Allowed Methods–>
<descriptor type=”Fieldtypes.ExtendedGeneralLink.ExtendedGeneralLinkForm” hint=”ExtendedGeneralLinkForm.OnModeChange” methodName=”OnModeChange” assemblyName=”Fieldtypes”/>
</allowedMethods>
<allowedPatterns>
<!–Default–>
<pattern value=”^Sitecore..*,Sitecore..*$”/>
<!–Add additional allowed method patterns–>
<pattern value=”^Fieldtypes..*,Fieldtypes..*$”/>
</allowedPatterns>
</reflection>
</sitecore>
</configuration>
In our situation, we encountered an issue where multiple “allowedMethods†were present, and we added all the methods in the patch file. However, after deployment and verifying it using the showconfig file, only the last method was added within the allowedMethods.
Upon reviewing the patch files, we realized that since all the “allowedMethods†belonged to the same class and we were not using the “hint†attribute, it took only the last method. Once we added the “hint†attribute, our issue was resolved.
Click the “GitHub – Reflection Filtering Patch†link to access the detailed configuration needed to resolve the reflection issue.
The GitHub config file changes were initially implemented for the “Extending General Link for Experience Editor†enhancements. Everything was functioning correctly, along with additional patch file configurations for reflections. However, after thorough testing, we decided to optimize our code and reduce the number of allowedMethods.
Therefore, we introduced the “Extending General Link for Experience Editor Alternate Approach.†This new approach reduced the allowedMethods configuration from 7 to 1. The optimized allowedMethods code according to our alternate approach is displayed below.
<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration xmlns:role=”http://www.sitecore.net/xmlconfig/role/” xmlns:security=”http://www.sitecore.net/xmlconfig/security/” xmlns:patch=”http://www.sitecore.net/xmlconfig/”>
<sitecore>
<reflection>
<allowedMethods>
<descriptor type=”Fieldtypes.ExtendedGeneralLink.ExtendedGeneralLinkForm” hint=”ExtendedGeneralLinkForm.OnModeChange” methodName=”OnModeChange” assemblyName=”Fieldtypes”/>
</allowedMethods>
<allowedPatterns>
<pattern value=”^Fieldtypes..*,Fieldtypes..*$”/>
</allowedPatterns>
</reflection>
</sitecore>
</configuration>
Conclusion
We addressed the “Reflection Method†error by configuring the patch file hierarchy and implementing the proper method pattern. This ensured smooth functionality in our project. Additionally, we optimized our code by reducing the number of allowed methods following an alternate approach outlined in the “Extending General Link for Experience Editor Alternate Approach†enhancements. This streamlined our codebase, enhancing efficiency and reliability.
Hope this helps. Happy learning!
Source: Read MoreÂ
