SharePoint Online PermMask cached wrong in Local Browser Storage / Service Worker

[chr-sad]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

No response

Describe the bug / error

I am not sure, if this is the correct Issue-List to post this topic since it's about the SharePoint Online client side caching / API issue. We build solutions using PnP/Js (SharePoint Rest API) and use the "PermMask" information on ListItems for permission information.

Simplified calls like:

  const folderItem = await webRef.getFolderByServerRelativePath(folderServerRelativeUrl).getItem()
  const folderItemData = await folderItem.select('Id, UniqueId, PermMask').get()

In the Network-Tab we can see the request handled by SharePoint correctly without error, but the PermMask returned is not correct. E.g. the user has Permissions to upload documents to this specific folder if we have a look in SharePoint directly (UI) but if we check the permission mask, it says, the user has only read permissions.

If we then press F12 > clear the whole cache (incl. service worker) with "Application" > "Storage" > "Clear site data" and only refresh the page (no code changes) we do get the correct PermMask and everything is working again.

This issue is happening for multiple users in multiple tenants now, but not reproduceable (at least for us) and reoccuring over time even if we removed the cache once.

Is anyone experiencing the same issues?

Steps to reproduce

We cannot finally reproduce this issue in steps. The only thing which is the same for all effected users that the only solution is to clear the cache incl. service worker.

Expected behavior

If the service worker is caching the list item incl. PermMask it should handle the update of the cache correctly in every case (e.g. even if the permissions are updated by Rest API calls as well)

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[chr-sad]

@nick-pape Do you know of anyone else experiencing this issue in their tenants or have any update on this issue?

[chr-sad]

This issue still exists since months and seems critical to me. I do not know if anyone reads this post so I add @nick-pape and @VesaJuvonen (sorry if I should not do it, then please let me know where to file such issues).

There is a difference in loading the folder permissions via renderListDataAsStream API with rootfolder and RenderOptions ListData (ListData.FolderPermissions) (returns the correct PermMask all the time in our tests) and loading the PermMask by item (returns the correct PermMask only the first time and caches it in an incorrect way).

If we use this code:

  const folderItem = await webRef.getFolderByServerRelativePath(folderServerRelativeUrl).getItem()
  const folderItemData = await folderItem.select('Id, UniqueId, PermMask').get()

the first request is correct and cached. If the user then gets other permissions, the request still returns the old PermMask. It is reproduceable in our tenant - for example:

• an admin user (User A) grants some user (User B) only read permissions on the folder via PowerShell (CSOM)
• User B opens the page, where the API request the PermMask by folder item > the PermMask is correct and the user has only read permissions
• User A grants the same User B more permissions on the folder afterwards so the user can now upload documents / create documents (with PowerShell (CSOM))
• User B opens the page again, where the API request the PermMask by folder item > the result is wrong (it is the old PermMasked cached with only read permissions). Even CTRL + F5 is not solving the issue, waiting for multiple days is not solving the issue, only disable cache in Dev-Tools + Clear-Site-Data (clear Service Worker) + CTRL + F5 solves the problem for one user.

[Ashlesha-MSFT]

@chr-sad,
Thanks for the detailed analysis and follow-ups.

We’re reviewing this from our end and would like to confirm whether this issue is still ongoing for you. If it is, could you please help us with:

• A step-by-step reproduction of the issue, ideally using a test user with permission changes, so we can simulate it in our tenant.

• Any recent findings or workarounds beyond clearing local cache and service worker data.

• Confirmation whether you're still seeing the stale PermMask values returned after permission changes (even after a hard refresh), and if so, which specific API calls trigger the issue most consistently.

• Understanding this will help us determine if this is a SharePoint Online platform bug or if there are alternative approaches we should consider.

[chr-sad]

@Ashlesha-MSFT sorry for the delay but now I had the time to rethink through this issue and reproduce it step by step which took some time. I used "SP Editor" in Microsoft Edge this time to perform the requests - exactly the same procedure I mentioned in this ticket:

/* Hit 'ctrl + d' or 'cmd + d' to run the code */
/* Check output from browser console */

import { spfi, SPBrowser } from "@pnp/sp/presets/all";
//import { InjectHeaders } from "@pnp/queryable";

const sp = spfi().using(SPBrowser({ baseUrl: (window as any)._spPageContextInfo.webAbsoluteUrl }))
           /* onPrem might need verbose headers
           .using(InjectHeaders({Accept: 'application/json; odata=verbose'}))*/;

(async () => {
  const listServerRelativeUrl:string = '/sites/<somesite>/UploadDocumentLibrary';
  const folderServerRelativeUrl:string = '/sites/<somesite>/UploadDocumentLibrary/AAA Test';
  const folderItem = await sp.web.getFolderByServerRelativePath(folderServerRelativeUrl).getItem()
  const folderItemData = await folderItem.select('Id, UniqueId, PermMask')()
  console.log(folderItemData);

  //render list data as stream
  const viewXml = `
    <View Scope="RecursiveAll">
      <RowLimit Paged="FALSE">1</RowLimit>
      <ViewFields>
        <FieldRef Name="ID" />
        <FieldRef Name="UniqueId" />
        <FieldRef Name="PermMask" />
      </ViewFields>
    </View>`;

  // Call RenderListDataAsStream on the list and limit it to the folder
  const resp = await sp.web.getList(listServerRelativeUrl).renderListDataAsStream({
    ViewXml: viewXml
    // optional: RenderOptions, RowLimit, etc. See docs if you want paging
  });

  //we made sure, the first row is the folder "AAA Test" and only compared this value
  console.log(resp);

})().catch(console.log)


----
First Run - User has only read permissions > check with API:
PermMask = "0xb008431061" >> OK
PermMask from renderListDataAsStream = "0xb008431061" >> OK
----
Second Run - User got contribute permissions > check with API: (without STRG + F5)
PermMask = "0xb008431061" >> WRONG
PermMask from renderListDataAsStream = "0x1b03c4312ef" >> OK

Third Run - STRG + F5 > another execute:
PermMask = "0xb008431061" >> WRONG
PermMask from renderListDataAsStream = "0x1b03c4312ef" >> OK

4. Run - Application > Clear Site Data, Network > Cache STILL ENABLED > another execute:
PermMask = "0xb008431061" >> WRONG
PermMask from renderListDataAsStream = "0x1b03c4312ef" >> OK
----
5. Run - Restart browser > another execute:
PermMask = "0x1b03c4312ef" >> OK
PermMask from renderListDataAsStream = "0x1b03c4312ef" >> OK

or (another complete run with all steps starting from first)

5. Run - Application > Clear Site Data, Network > Disable Cache > STRG + F5 > another execute:
PermMask = "0x1b03c4312ef" >> OK
PermMask from renderListDataAsStream = "0x1b03c4312ef" >> OK

For my understanding a little bit has changed - the time when I created the ticket, the problem seemed to persist over multiple days. In todays tests after restarting the browser, the permission changes where reflected in the permmask in both APIs. But still I think this is a problem, since the APIs behave inconsistent as you see in my logs.

I hope this helps.