Confluence 11.0 release EAP available now

Hi

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.

Hi sandeep,

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.

Cheers

Bernhard

Thanks @HimanshuTanwar for the answer.

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.

Thanks

Andrea

Hi Atlassian Team,

How can we handle adding “nonceId” to scripts embedded in VM files in web panels?

atlassian-plugin.xml

<web-panel key="custom-confluence-web-panel-resources" name="custom-confluence-web-panel-resources" location="atl.header" weight="10">
    <context-provider class="com.itlab.confluence.plugins.test.panel.SystemPanel"/>
    <resource name="view" type="velocity" location="templates/panel.vm"/>
    <label>custom-confluence-web-panel-resources</label>
</web-panel>

panel.vm

...
<script>
   alert(1);
</script>
...

SystemPanel

...
import com.atlassian.plugin.web.ContextProvider;

...

public class SystemPanel implements ContextProvider {

    private static final Logger log = LoggerFactory.getLogger(SystemPanel.class);

    @Inject
    public SystemPanel(){ }

    @Override
    public void init(Map<String, String> map) throws PluginParseException { }

    @Override
    public Map<String, Object> getContextMap(Map<String, Object> map) {

        return map;

    }
}
..

Cheers

Adam





Hi @AndreaSerra , @adam.labus ,

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.

You can use the client side API of the Atlassian Web-resource module to load web-resources declared in the plugin.

Assuming you have a plugin with a web-resource:

<atlassian-plugin name="Sample plugin" key="example.plugin.myapp" plugins-version="2">
    <web-resource key="async-code" name="Async code for the app" >
        <resource type="download" name="async-code.js" location="my-app/async-code.js" />
    </web-resource>
</atlassian-plugin>

Then you can invoke the runtime API to load it:

const wrmRequire = require('wrm/require');
wrmRequire.require('wr!example.plugin.myapp:async-code')
  .then(() => console.log('resource loaded'));

The return value is a Promise<void> extended with a few methods for backward compatibility with jQuery.

The function accepts two arguments:

  1. {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)
  2. {() => 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.

I hope that helps!

Jiri

Hi there,

I checked m116 pageManager but I could not find a getPageIds method.
Could you please double check?

Thank you!
Cedric

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.

Hi @PumpeCedric
I just verified, its available in 11.0.0-m117. m116 was cut before the fix was merged.

@cheinig

You can find an equivalent REST API your app for these requirements.

For example: countCurrentBlogs can be translated to totalSize in:
{{baseUrl}}/rest/api/content/search?cql=type=blogpost&status=current&limit=1

You can also add more filters like: space="{{spaceKey}}"

Please let me know if you further questions

Answered here: Major release updates for Data Center - #5 by ggautam

Is this really equivalent? The REST API probably respects view permissions, reducing the number – and it’s not very pleasant to call from Java code.

I guess we could also use something like this?

import com.atlassian.confluence.security.PermissionManager;
import com.atlassian.confluence.api.service.search.CQLSearchService;

permissionManager.withExemption(() -> {
  PageResponse<Content> response = cqlSearchService.searchContent(
    "type=blogpost&status=current",
    new SimplePageRequest(0, 1)
  );
  Optional<Long> totalCount = results.getTotalCount();
}

Hi @ggautam

thank you for your answer and suggestion.

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.

Cheers

Adam

Hi @cheinig,

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.

Thanks

Hi @adam.labus

Spot on, if you need it on the UI, then REST API can come handy with some refactoring in your app’s frontend code.

For in-process Java API use cases, please consider using CQL Search equivalent with caveat of being eventually consistent.

Thanks

Hiya. For some reason, our custom macro is no longer appearing in the macro browser on the latest Confluence 11 milestones.

This only occurs when editing an already existing page. If a brand new page is created, the macro is accessible as usual.

This appears to have been introduced in 11.0.0-m116. In the previous milestone (11.0.0-m79), all works as usual.

I have also been able to reproduce this with the hello world macro. A simple xhtml-macro definition in the atlassian-plugin.xml will cause it:

<xhtml-macro name="helloworld" class="com.atlassian.tutorial.macro.helloworld" key='helloworld-macro'>
    <description key="helloworld.macro.desc"/>
    <category name="formatting"/>
    <parameters/>
</xhtml-macro>

We also add an entry into the featured macros list (“Insert more content” in the editor toolbar) via the following in the plugin XML:

<web-item key="editor-featured-macro-item" name="Featured Macro Item" section="system.editor.featured.macros.default" weight="10">
    ...
</web-item>

The listing still appears there, however upon clicking I’m presented with:

I am testing using a standalone instance via atlas-run-standalone at version 11.0.0-m177 (or anything above m79) under Java 25.

To reproduce:

  1. Create the hello world macro via the tutorial
  2. Boot a standalone instance via atlas-run-standalone at version >m79
  3. Install the hello world app
  4. Create a new page and save it
  5. Re-edit the page, and attempt to add the macro

The macro will not be available in the browser.

Is anyone else experiencing this?