The error message suggests you are using a new Blob to load the service worker code. If so, try replacing it with a JavaScript file with a web resource entry. This way, the URL won’t be dynamic, and you won’t need to create a CSP fragment.If you are loading the code some other way then please share some more details regarding that for us to analyse.
Thanks for the info. I was already on my way of doing so. Sometime ago that blob approach made sense. But I already found a solution that might work, I will report here once I got it implemented and tested.
What’s the WASM-specific threat model behind the decision?
W3C CSP3 split unsafe-eval and wasm-unsafe-eval because they describe different capabilities. unsafe-eval turns strings into live JS in the origin. wasm-unsafe-eval compiles static bytes into sandboxed code that can’t touch DOM, fetch, cookies, or JS state unless the host passes imports in.
Concretely: what can a malicious WASM payload do on a Confluence page that the surrounding CSP-allowed JS can’t already do? “Nothing new, but we can’t audit plugin WASM content” would be a reasonable conservative answer and worth stating outright. If there’s a WASM-specific escape or abuse pattern we’re missing, we’d like to see it so partners can think about mitigations.
The practical reason this matters: we have thousands of customers. We can’t route every one of them to support to ask their admin to enable an obscure CSP system property they’ve never heard of, without a documented reason for it. That won’t work at our size or theirs.
If the system property is the final word, please publish the technical rationale. Without that, we have no credible answer for customers asking “why does this plugin need the security settings weakened?”
Our remaining option is to rewrite the plugin to parse SQLite server-side, which is a time consuming effort we’d rather not start without knowing whether the decision is settled.
in reference to deferred or lazy loading static resources above:
The previous solution didn’t require us to load additional files per page (web-resource in editor context). Unfortunately, now we have to prepare them in advance and add them to almost every page load – we tested the new solution and it works, but it requires loading scripts into the page in the editor context.
The return value is a Promise<void> extended with a few methods for backward compatibility with jQuery.
The function accepts two arguments:
{string|string[]} resource (required) is a string or array of strings with web-resources or contexts, each of them prefixed:
use wr! for requiring web-resource
use wrc! for requiring web-resource context (e.g. wrc!editor)
{() => void} callback (optional) Callback to call after the web-resource/context has been loaded
If you need this async code to be dynamically generated, you can use server-side web–resource transformers.
Our documentation does not have the javascript API documented too well but you can refer to its code.
As a higher level alternative, you could also opt to use Bitbucket (works with Webpack and Rspack) that transforms dynamic imports import('./file').then() to the javascript wrm/require API automatically.
Hi @AndreaSerra
Thanks for your patience.
After internal discussions, we have decided that for this particular use-case we will add wasm-unsafe-eval by default from Confluence side.
I’m on @cheinig side - a REST API might not be the best way to call directly from Java code. I also think the idea of calling CQL from Java code isn’t ideal either. Sometimes, there’s a tiny delay between when a page or post is created and when it shows up in the CQL results.
Maybe it would be a good idea to recreating the countCurrentBlogs() method and include the getBlogPostByTitle(String spaceKey, String title) method from BlogPostDao.
You can use CQLSearchService for backend Java API only calls. As Adam mentioned, CQL is based on indexing and its bound by eventual consistency.
Note that the mentioned REST APIs are for UI to consume, not in-process method calls.
when trying to install the plugin, I get the following exception:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'xzy': Unsatisfied dependency expressed through constructor parameter 3: Error creating bean with name 'xyz': org/slf4j/spi/LocationAwareLogger
It seems that slf4j is not provided by Confluence anymore. Is this intentional? Am I supposed to bundle my own version?