Confluence 11.0 release EAP available now

Hi everyone,

A Confluence 11.0 EAP milestone is now available. EAP releases provide a snapshot of our work in progress and give you an opportunity to test and fix your apps before the final release.

During the development of Confluence 11.0, we’ll release monthly milestones and betas. To find out what’s changed, head to Preparing for Confluence 11.0

Get the latest EAP

If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.

Enjoy!

The Atlassian Confluence team

We now announce Confluence Data Center releases and more in the Atlassian developer changelog. Subscribe to the changelog to receive the latest updates.

Hi @AleksandraWieczorek

Thank you for officially sharing it.

From my initial observations, it appears that some *Dao classes have been moved and are no longer available for us.

Looking at our code, we’re missing an equivalent to the getBlogPostByTitle(String spaceKey, String title) method from BlogPostDao.

Is there an alternative in the PageManager class (I haven’t found one) or should it be added to it?

Cheers

Adam

FYI @Kusal

Hi,

are there any Plattform major level upgrades?

Or other breaking changes?

Hard to believe that a major level version step from 10 to 11 does not bring any breaking changes.

The preparing page did not really contain any information about that.

Thanks

I’m genuinely surprised that a product with an announced end-of-life date is still doing major version releases.

I can only hope that the move from 10 → 11 is much smoother than the jump from 9 → 10 was, both in terms of development/testing (looking at you javax → Jakarta), as well as the ongoing burden of managing multiple builds/releases of our apps targeting each major.

For much of the lifetime of our apps we were able to have one build that worked across Confluence 6.x - 9.x. That ended with v10, and we now publish two version of every release (one for 6.x-9.x, and another for 10.x); and this was further complicated by the new process that requires every new version to go through an automated approval step which adds a minimum of 10-15 minutes to each version published.

If 11.x requires us to add a third build, we’ll have to seriously consider whether it’s worth continuing to offer DC versions given the dwindling expected sales.

Hey there!

I ran into two problems:

  1. Running lombok under JDK 23+ you need to add lombok as annotation processor: Maven :check_mark:

  2. Package com.atlassian.mail.queue is not present when importing com.atlassian.mail.queue.MailQueueItem; :cross_mark:

Just my 2 cent…

Agree, if not totally necessary it should be in maintenance mode otherwise these platform upgrades (as these are more challenging) can lead to upgrade fatigue because “someone“ is migrating in x-months anyhow. I think every customers knows already how the deal with the regular jQuery finding :smiley:

If i’m not wrong, we had a CVE with a score of 10 on Confluence 8.x due to the underlying switch from WebWork to Struts. So these platform changes will not automatically increase security.

Hi @clouless, @scottohara

Confluence 11 will include the changes described in From stable to unshakeable: announcing upcoming major releases for Atlassian Data Center.

We are working on the changes internally, including migrating our plugins. From that work, we expect the next major to be easier to adopt than javaxjakarta migration. However, breaking changes may occur.

Note that the list of changes is not exhaustive and omits product-specific changes.

Hey there!

I tested agains m79 and what I found was that the PageManager no longer comes with the following method:
@NonNull Collection getPageIds(Space var1);

Is this intentional? If so, what’s the recommended replacement?

Best,
Cedric

Hi Team! Thanks for the resources as usual – I appreciate all the security work you’re doing!

I dug a bit deeper into the CSP requirements for our app (PocketQuery for Confluence) and ran into a bit of a roadblock regarding the strict block on unsafe-eval mentioned in the preparation docs.

Our app relies heavily on Google Charts (gstatic.com/charts/loader.js) for data visualization. While we can easily solve the inline script requirements, we found that the internal architecture of Google Charts fundamentally relies on eval() and new Function() to load and execute its dynamic modules.

Because we don’t control the Google Charts loader source (and Google officially doesn’t support completely offline, eval-free bundling), the strict CSP would entirely break chart rendering. Based on our analysis, our only paths forward right now are:

  1. Ask our customers to globally disable strict CSP via the JVM property (not an option).

  2. Completely rip out Google Charts and migrate to a new eval-free charting library (not really a feasible option as it’s a massive breaking change on our end).

What other options would we have to resolve this issue?

Thanks!

Hi @PumpeCedric
Thanks for the feedback, we have restored the original getPageIds method in PageManager, hopefully that helps.

We are trying to reduce unused methods available in public API, please let us know if you further feedback.

Regards,
Ganesh

Hi Atassian Team,

Is it possible to get the nonce id for our scripts via data provider? this would make it much easier to dynamically load some scripts/libraries instead of loading them every time

Cheers

Adam Labus

Could you also restore countCurrentBlogs() or point us to an equivalent?

Thanks,
Christian

(edit: I posted this just before receiving the mail notification about your answer in the other thread:grinning_face_with_smiling_eyes:)

Confluence 11 strict CSP and WebAssembly: am I reading this right?

Reading the CSP section of Preparing for Confluence 11.0, I want to check my understanding before I rework a plugin the wrong way.

The default script-src in Confluence 11.0.0-m116 with http.header.security.content.security.policy.strictness.enabled=true contains neither 'unsafe-eval' nor 'wasm-unsafe-eval'. Chrome and Firefox therefore reject WebAssembly.instantiate():

CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly
module violates ... 'unsafe-eval' is not an allowed source of script ...

I can load and serve my own .wasm file fine (HTTP 200, application/wasm). The failure is purely the CSP policy rejecting WASM compilation.

And unless I’m missing something, CspFragment can’t fix this from the plugin side: getCSPOrigins returns Set<URI>, so I can whitelist external origins but not keyword sources like 'wasm-unsafe-eval'. I checked the <csp> module descriptor, the plugin XSD, com.atlassian.security.csp.api.*, Confluence’s CSP packages, and <web-resource> attributes. Nothing grants keywords.

So my read is that under strict CSP, no Confluence 11 DC plugin can ship client-side WebAssembly. That rules out sql.js, pdfkit/fontkit (harfbuzz-WASM), pdfium, Mermaid, Graphviz WASM builds, image codecs, client-side ML, anything compiling WASM at runtime. Even though 'wasm-unsafe-eval' exists precisely to permit WASM without opening up string-eval. W3C CSP3 defines it as a narrower, sandboxed keyword (see the WebAssembly CSP proposal).

Is that actually the intent? Two questions:

  1. Will 'wasm-unsafe-eval' be added to the default script-src before strict CSP flips default-on?

  2. If not, is there any plugin-side mechanism I’ve missed to contribute keyword sources?

For context on my side: Balsamiq Wireframes for Confluence parses .bmpr (SQLite) files client-side via sql.js. We already moved from sql.js 0.4.0 asm.js (eval-based) to sql.js 1.x WebAssembly, which is exactly the direction the docs push. Everything else on the CSP checklist is done: inline scripts nonced, onclick handlers removed, no eval or new Function anywhere in our code. The WASM instantiation is the only thing left, and as far as I can tell there’s no code change on my side that fixes it.

Would appreciate a sanity check from anyone who’s been through this, especially if 'wasm-unsafe-eval' is already on the roadmap or there’s an API I overlooked.

Will this also impact WebWorker API js files? ( Web Workers API - Web-APIs | MDN )

Currently our app has a WebWorker JS file for syntax highlighting that communicates via the WebWorker API with the normal ReactJS frontend code.

:red_circle: yes it does not work.

I just tested against m116 with enforced CSP

-Dhttp.header.security.content.security.policy.strictness.enabled=true

I use this to load the webworker (works in confluence 10 and 11 without the enforced CSP):

    <web-resource key="resources-highlight-webworker" name="my-codeblocks Web Resources Highlighter WebWorker">
       <resource type="download" name="advanced-highlight-bundle.js" location="/iife-highlight-bundle/my-highlight-bundle-1.0.0.min.js"/>
       <context>atl.general</context>
       <context>macro-browser</context>
       <context>main</context>
    </web-resource>

and the error I get is:

Refused to load blob:http://192.168.1.66:8090/a2125f68-f621-4ea6-b05d-15cae20d6814 
because it does not appear in the worker-src directive 
of the Content Security Policy.

how can I allow it? the URL seems to be dynamically rewritten …

In my react code I do this:

  importScripts('https://baseurl/iife-highlight-bundle/my-highlight-bundle-1.0.0.min.js');
  onmessage = function (event) {
    var result = advanced.ac_highlight(event.data.lang, event.data.code);
    postMessage(result);
    close();
  };
...

thanks

Thanks for testing and sharing the details Bernhard, very useful to see another case.

Unfortunately I think we are in the same boat. The CspFragment API only allows whitelisting URI origins, it does not support adding keywords like blob: to worker-src or wasm-unsafe-eval to script-src. So there is no way for us as plugin developers to solve this on our side.

We are waiting for Atlassian to address this. A lot of marketplace plugins will stop working if these gaps are not covered before CSP is enforced by default.

Yes unfortunately it seems this way… I hope Atlassian will find a solution that still makes it safe but allows us Marketplace Vendors to use state of the Art Browser APIs :blush:

Hi,

Regarding the use of unsafe-eval, we do not plan to add that property. For the scenario you described, the recommended approach is to consult the Google Charts team and request a safer version of the library.
Additionally, could you provide the specific code paths that invoke eval and new function? The provided link to the library shows no direct usage, though it loads other internal libraries. Identifying which of those libraries is responsible for the issues in your use case would be helpful.

Hi @adam.labus
Could you describe the scenario that could only be addressed by data providers for obtaining a nonce value, and that cannot currently be resolved using existing mechanisms?
At present, we do not intend to expose the nonce value through data providers.

Hi @AndreaSerra

Regarding the inclusion of the wasm-unsafe-eval property, Confluence will not ship with this property enabled by default for all users and also not allow to add this using CSPFragment. Instead, we will offer a system property that allows Confluence administrators to activate it if needed.

Hi @HimanshuTanwar

Sure, we use additional libraries for coloring page code. Until now, we loaded them (we added script tags and adding them to the header tag) only when a button was clicked (a conscious user action).

This solution now doesn’t meet the new “nonce” requirement. If we had a nonceId in the data provider, I assume the mechanism wouldn’t have to change.

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.

Cheers

Adam