Sp-dev-docs: Access Denied exception in Tenant root Site Collection only

[CANUSA]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Launching an App fails in the root Site Collection of a Tenancy with an Access Denied exception, whereas launching an App in ANY other Site Collection in the Tenancy works as expected.

Expected or Desired Behavior

I expect the App to launch successfully in ANY Site Collection, including the root Site Collection of the Tenancy.

Observed Behavior

I created 3 separate Tenancies to test this. I was able to observe the Access Denied exception in the root Site Collection of all 3 trial tenancies. I observed the App successfully launch in 10 non-root Site Collections in each tenancy.

Steps to Reproduce

Create an app with, in my case, Site Collection [Read] and Site [Full Control] permissions and leverage them in your PHA to read or modify your root Site Collection, and subsequently, any other Site Collection, upon App launch. I observe an Access Denied exception in each root Site Collection.

In my case I am adding a folder and a file to the root web's root folder in the root site collection of the tenancy.

UPDATE
The folder and file I am adding above are actually being added in the App Web, by my App installed in the root web of the root site collection of the tenancy. My APP is getting an Access Denied trying to write to its OWN App Web.

[CANUSA]

Temporarily closing, doing some further research...

[CANUSA]

I am seeing the same behavior in sub webs of the root Site Collection of the tenancy as well, not just the root web,

[webdes03]

I have tested this in one of my tenants and have confirmed the same behavior. App deploys just fine to any site collection outside of the tenants root, but throws the error described on all webs within the tenant's root site collection.

[douglasware]

This is similar to intermittent issues I've seen over the last 18 months where random customers are unable to install marketplace apps because of Access Denied to app webs, and may be the same problem. However, I believe some of the affected users were in site collections other than the root.

[douglasware]

It's been a little while, but speak of the devil, we just got a support request from someone getting this error trying to install our store app. This bug is essentially why I finally gave up on trying sell apps through the store last year... the straw that broke the camel's back as it were.

[VesaJuvonen]

Any chance we could get a repro for this from someone as an example app or correlation ID on the exception (it's visible in F12) - just to speed up the resolution and investigation?

[CANUSA]

This is related to our discussion at SPCNA @VesaJuvonen . Essentially, the fact that the AddAndCustomizePages permission mask is not present in the root site collection of a tenant prevents our app from launching. In this case, our app creates a folder and a couple of pages in the user's site, and of course they reference external scripts. Our app has full control of the site (WebFullControl). These types of apps should not even be allowed to be added to a site in the root site collection as the FullControl contract is clearly being broken in this case (although this is undesirable). Really what we would prefer is guidance on what we need to do to allow the app to be launched to be presented, like we have in our documentation, or ideally, allow apps to do this but not users, and yes, I understand that an AppOnly permission is just a user, :). Any app that creates a page should be able to reproduce this in any root site collection. In addition to being blocked in the user's site, we are also blocked in the app web from doing this, which technically is still just a site in that site collection, but a major reason an app web ever existed was to isolate its permissions (including AddAndCustomizePages), which now don't even exist there. Hope this helps. Let me know if you need anything else.

Our guidance now includes a reference to this PS command (https://support.office.com/en-us/article/allow-or-prevent-custom-script-1f2c515f-5d7e-448a-9fd7-835da935584f) to allow users to add the permission back in, then remove it after installing or upgrading our app.

Set-SPOsite -DenyAddAndCustomizePages 0

It appears that this is a problem in modern group sites as well. This means our app is essentially unusable without the assistance of a tenant admin. :(

[lucaband]

We are closing this issue because it is "by design".

Now, we understand that this is not the right design and we are working on APIs that, at least for modern, will allow to create pages without requiring to turn NoScript off.
For now, the only workaround is to have the app checking if the permission is not part of the Permission Mask and fail gracefully.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues