powershell icon indicating copy to clipboard operation
powershell copied to clipboard

Published 20 hours ago • verified publisher icon pnp

Add-PnPApp throws System.UnauthorizedAccessException when custom script is blocked on app catalog

Open thomaskjaerulff opened this issue 1 year ago • 6 comments

Reporting an Issue or Missing Feature

We have discovered that when the Custom Script setting is set to "Blocked" on the app catalog site, we are unable to release our SPFx web part using the Add-PnPApp cmdlet. We receive a System.UnauthorizedAccessException.

image

image

If we change the setting to "Allowed", it works fine.

Expected behavior

We expect to be able to release our SPFx web parts using the Add-PnPApp cmdlet without having to first run Set-PnPSite -NoScriptSite $false

Steps to reproduce behavior

Set the Custom script setting to "Blocked" on the app catalog site and run the Add-PnPApp cmdlet on this site.

What is the version of the Cmdlet module you are running?

Running PnP.PowerShell 2.10.0

Which operating system/environment are you running PnP PowerShell on?

  • [X] Windows
  • [ ] Linux
  • [ ] MacOS
  • [ ] Azure Cloud Shell
  • [ ] Azure Functions
  • [ ] Other : please specify

thomaskjaerulff avatar Aug 29 '24 14:08 thomaskjaerulff

Does it work releasing the spfx package through the UI on SPO or do you get an error there too ?

jackpoz avatar Aug 29 '24 18:08 jackpoz

I also receive an access denied when uploading any given SPFx package through the UI with custom scripts set to "Blocked" and me being a Site Admin on the App Catalog site.

image

thomaskjaerulff avatar Aug 30 '24 06:08 thomaskjaerulff

This is by design, not a bug. You will need to unblock in order to upload the app.

gautamdsheth avatar Aug 30 '24 09:08 gautamdsheth

So the policy is not to add that check to the various commands ? That is one way to do it, but it puts the burden on every user, rather than handling this quietly in the command

kasperbolarsen avatar Aug 30 '24 09:08 kasperbolarsen

A new optional parameter might be a good trade-off between respecting the policy by default and providing a convenient way to users to override it, as long as they have the permissions to flip the Custom scripts setting to Allowed.

Would that be an acceptable solution ?

jackpoz avatar Aug 30 '24 10:08 jackpoz

I think the policy should be covering all the CMDs where the blocking of Custom Scripting is an issue. So the option is:

  1. Leave it up to the end users to modify their scripts ( can we provide a list of CMDs that require Custom Scripting?)

  2. add the optional parameter

  3. add the handling of Custom Scripting activation in the CMDs.

I would of course prefer #3 but I have no idea about how many CMDs that we are talking about

kasperbolarsen avatar Aug 30 '24 14:08 kasperbolarsen