Sample
https://github.com/pnp/sp-dev-fx-extensions/tree/main/samples/js-application-analytics
Author(s)
@giuleon, @bernierh, @joao12ferreira, @NicolasKheirallah
Question
I had flagged this in discussions here however flagging here as could really do with seeing however others got round this
Hi all,
Looking to sense check how others are handling recent CSP changes in SharePoint Online.
We have been using the sample solution for a number of years that injects JavaScript (via Script Editor / similar approach) to support analytics tracking. This has been stable for a long time.
However, following the CSP updates rolled out around March, we’re now seeing this blocked. The script is being flagged as inline and prevented from executing.
From what I can see, this is expected behaviour with the stricter Content Security Policy now being enforced, particularly around inline scripts and allowed domains.
Our current thinking is that this approach is no longer viable long-term, and the provided sample solution will need to be refactored:
• SPFx-based extension (Application Customizer)
• External JS hosted and referenced in a compliant way
• Potentially rethinking how tracking is implemented altogether
Before we go too far down that route, I wanted to ask:
• Are others seeing the same behaviour post-CSP changes?
• Have you successfully worked around this without moving the entire JavaScript into discrete files?
• If you’ve moved to the JavaScript to discrete files, any patterns or gotchas worth being aware of (particularly around analytics / tracking scenarios)?
• Any issues with CSP when loading external scripts (e.g. Google Analytics domains)?
Keen to understand what “good” looks like now in a CSP-compliant world, especially for scenarios that previously relied on lightweight script injection.
Appreciate any insight or examples.
Thanks in advance,
Chris
Sample
https://github.com/pnp/sp-dev-fx-extensions/tree/main/samples/js-application-analytics
Author(s)
@giuleon, @bernierh, @joao12ferreira, @NicolasKheirallah
Question
I had flagged this in discussions here however flagging here as could really do with seeing however others got round this
Hi all,
Looking to sense check how others are handling recent CSP changes in SharePoint Online.
We have been using the sample solution for a number of years that injects JavaScript (via Script Editor / similar approach) to support analytics tracking. This has been stable for a long time.
However, following the CSP updates rolled out around March, we’re now seeing this blocked. The script is being flagged as inline and prevented from executing.
From what I can see, this is expected behaviour with the stricter Content Security Policy now being enforced, particularly around inline scripts and allowed domains.
Our current thinking is that this approach is no longer viable long-term, and the provided sample solution will need to be refactored:
• SPFx-based extension (Application Customizer)
• External JS hosted and referenced in a compliant way
• Potentially rethinking how tracking is implemented altogether
Before we go too far down that route, I wanted to ask:
• Are others seeing the same behaviour post-CSP changes?
• Have you successfully worked around this without moving the entire JavaScript into discrete files?
• If you’ve moved to the JavaScript to discrete files, any patterns or gotchas worth being aware of (particularly around analytics / tracking scenarios)?
• Any issues with CSP when loading external scripts (e.g. Google Analytics domains)?
Keen to understand what “good” looks like now in a CSP-compliant world, especially for scenarios that previously relied on lightweight script injection.
Appreciate any insight or examples.
Thanks in advance,
Chris