AccessDeniedException Calling Spe.Client.Applications.UploadFile.PowerShellUploadFileForm.CancelClick or OKClick

[Rhaguen]

Using Sitecore Power Shell 6.4 on a Sitecore 9.1 instance.

Expected Behavior

Expect script to upload a file trough Receive-File

Actual Behavior

Get an exception:

[AccessDeniedException: Calling Spe.Client.Applications.UploadFile.PowerShellUploadFileForm.CancelClick method through reflection is not allowed.] Sitecore.Reflection.MethodFilter.Filter(MethodInfo method) +1166 Sitecore.Shell.Framework.Commands.CommandManager.GetMethodCommand(String command) +701 Sitecore.Web.UI.Sheer.ClientPage.Dispatch(String command) +35 Sitecore.Web.UI.Sheer.ClientPage.RaiseEvent() +124 Sitecore.Web.UI.Sheer.ClientPage.OnPreRender(EventArgs e) +806 System.Web.UI.Control.PreRenderRecursiveInternal() +200 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Steps to Reproduce the Problem

• Security Bulletin SC2023-003-587441 path must be installed.
• Click on either Ok or Cancel buttons from the Receive-File modal window throws the exception. Regardless of having or not a file selected.

Potential fix tried

As highlighted by the Security Bulleting page, tried to path exceptions for the mentioned methods on Sitecore.Reflection.Filtering.config.
I tried #1, then #2 and then #3. Finally all toguether, just to be sure.
Problem still persists.

Could it be a know issue? Thanks in advance of any advice.

• Tested issue with clean install of Sitecore and the latest available version of SPE.

• Asked questions on the Sitecore Slack Chat channel.

• Reviewed questions and answers on the Sitecore Stack Exchange.

[michaellwest]

https://sitecore.stackexchange.com/a/35330/95 and #1308 outline steps to address.

[Rhaguen]

Thanks for the quick response, Michaell.
Unfortunately patching allowedMethods exceptions, as described on my original question, gave no positive feedback.

<descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="OKClick" assemblyName="Spe" hint="Ok"/> <descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="CancelClick " assemblyName="Spe" hint="Cancel"/>

Also, I'm already running the latest version of Sitecore Power Shell.

[draydev-sc]

Using SPE 6.2, the CancelClick and OKClick methods of the PowerShellUploadFileForm type are now functioning for me using the following configuration to whitelist methods called via reflection; however, I'm having trouble producing the error alerts via the ShowError and ShowFileTooBig methods. Are these also initiated via reflection, and/or would you recommend adding them to the whitelist?

<?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="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="CancelClick" assemblyName="Spe" hint="Cancel"/>
            <descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="OKClick" assemblyName="Spe" hint="Ok"/>
            <descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="StartUploading" assemblyName="Spe" hint="StartUploading"/>
            <descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="EndUploading" assemblyName="Spe" hint="EndUploading"/>
            <descriptor type="Spe.Client.Applications.UploadFile.PowerShellUploadFileForm" methodName="ShowError" assemblyName="Spe" hint="ShowError"/>
        </allowedMethods>
      </reflection>
    </sitecore>
</configuration>

[michaellwest]

For clarification, the reflection filtering was something Sitecore added without directly involving the SPE team. The inner workings of how it prevents methods from running is a bit of a mystery. I wouldn't be surprised if this changes in the next 10.x release.

[AdamNaj]

This should be addressed in commit 545fd9a provided as part of #1241