SPFX Application Customizer breaks Anonymous Links for PDF Files

[Anonimiss]

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

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

• browser version:
  • Firefox 101.0 (64-Bit)
  • Edge 102.0.1245.33 (64-Bit)
  • Chrome 102.0.5005.63 (64-Bit)
• SPFx version: 1.12.1
• Node.js version: v14.18.1

Describe the bug / error

I saw someone raised the same issue here, but it was marked closed.

Following the steps from Build your first SPFX Framework extension, I successfully packaged and deployed the hello world dialog popup example. After, creating an anonymous link for a PDF file breaks for users who are not signed into SharePoint.

This behavior does not happen every time and with enough attempts, I can successfully view the PDF. On average, it would fail 6-8 times out of 10 attempts. This experience is not intuitive for end users who will normally stop attempting to access the PDF after the first or second try.

Steps to reproduce

1. Follow the steps from Build your first SPFX Framework extension
2. Ensure skipFeatureDeployment is set to true in the package-solution.json file
3. gulp build/bundle/package-solution --ship and then deploy to SharePoint Apps repository
4. Verify the Hello World Dialog Popup Appears on SharePoint pages
5. Upload a PDF file preferably with 20+ pages
6. Create an Anonymous link for the PDF file
7. Launch browser in incognito mode and attempt to access the PDF with the anonymous link
8. The PDF viewer is a blank white screen, with dots running along the top to represent its loading (never finishes). Sometimes the PDF will successfully load, I am guessing its based on what asynchronous calls come first.

Expected behavior

If the extension detects the user does not have adequate permission, it should be disabled and allow the page to continue loading the resources the anonymous user has access to view.

[ghost]

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

[AJIXuMuK]

Thank you @Anonimiss for reporting this one!
We're actively investigating the issue.
In a meanwhile there are few workarounds I can think of:

• use the public CDN feature, and have the script on the public CDN that doesn't require authentication
• grant access to the folders for this solution in the App Catalog site collection similar to this one: https://www.crowcanyon.help/article/431/

[Anonimiss]

Thank you for your workarounds, @AJIXuMuK.

I first tried granting access to the folders in the App Catalog. Most pages I found referenced using the everyone group for doing this. Even with the everyone group, and all users group having read permissions, I was still facing the same issue.

Enabling the Microsoft 365 Public CDN looks to have solved my issue. I will continue to mess around with it, but the results are very promising!

Thanks again for the workaround.

[AJIXuMuK]

This should be fixed on our side too and rolled out WW

[ghost]

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