Confluence 9.1 release is available now

Hi everyone,

Confluence 9.1 is available now.

This release supports only Data Center licenses. If you have a Server license, check out your options for upgrading.

Download the latest version

What’s new?

  • Support for languages and special characters in page URLs
  • Code Block macro enhancements
  • Single click to copy heading links
  • More secure login with two-step verification
  • New REST APIs
  • Password policy
  • Microsoft Entra ID integration
  • Retention rules performance and reliability improvements
  • Lots more!

Check out the [Confluence 9.1 Release Notes] (Confluence 9.1 release notes | Confluence Data Center 9.1 | Atlassian Documentation) to learn more.

Reminder: for future release updates, make sure you visit the Atlassian changelog, and consider subscribing to the RSS feed.

I am having issues downloading the dependency com.atlassian.synchrony:synchrony-proxy:war:4.0.5 (absent) when starting Confluence with the Atlassian SDK.

I assume the artifact to be found here: Index of maven-external/com/atlassian/synchrony/synchrony-proxy

Am I mistaken or too impatient? :grinning:

Hi @rr1

if you use the bom platform dependency, try to update to a newer version, for me version 7.1.4 works without any problems

<confluence.version>9.1.0</confluence.version>
<platform.version>7.1.4</platform.version>

Cheers
Adam

1 Like

Hi @adam.labus,

Thank you for your quick reply!

Unfortunately it seems that I have another issue with my configuration.

Now I am using

        <confluence.version>9.1.0</confluence.version>
        <platform.version>7.1.4</platform.version>
        <jdk.version>17</jdk.version>

And AMPs version 9.1.1 (https://developer.atlassian.com/server/framework/atlassian-sdk/amps-9-1-1/).

The error message about the missing dependency is the same:

The following artifacts could not be resolved: com.atlassian.synchrony:synchrony-proxy:war:4.0.5 (absent)

I have removed the 4.0.5 subfolder from my repository with the intend to force Maven to load it again. Maybe this does not work with the current version of Maven?

I am still looking for which Confluence version goes with which platform version. I have only found https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7/, but this seems not to answer this question. Do you know where I can find the documentation for this?

I am also curious if a version of my app I compiled with a previous platform would run on a later platform (as long as there is no major version update of the platform).

Cheers,
Robert

Edit: It seems to start with AMPS 8.17.1 … not sure which version I should actually use … but I think I can figure this out … :face_with_head_bandage:

Hi @rr1

I checked the AMPS 9.1.1 version and in fact this problem also occurs in my case, I am currently using version 8.14.3 and everything works fine for Confluence 9.1 :wink:

Cheers
Adam

1 Like

Hi @adam.labus,

Thank you for taking your time for checking and confirming my issue with the latest AMPS version! At least I am not alone! :smiley:

I have checked with 9.0.6, 8.17.7, …, 8.17.3 and the last version that works for me with Confluence 9.1.0 is 8.17.2.

Just if anybody is interested … :partying_face:

Cheers,
Robert

We are using Velocity in Confluence 9.0 and previous versions via the class

com.atlassian.confluence.util.profiling.VelocitySitemeshPage

which seems to have moved to

com.atlassian.confluence.impl.sitemesh.VelocitySitemeshPage

I am not sure if this should state “do not use this anymore!” or if there is some configuration to make it work again. I had some difficulties with this code in the past (see Sitemesh on Confluence 9 and Greylist), but managed to cover Confluence up to version 9.0.

I basically would like to access properties of the page object via the getProperty method and receive the VelocitySitemeshPage as an argument to my registered Velocity method.

This is similar to what we see in How to display a banner like the Confluence Documentation Theme | Confluence | Atlassian Documentation, but I would like to pass the whole page. And I do not see any reference to this page object $sitemeshPage on https://developer.atlassian.com/server/confluence/confluence-objects-accessible-from-velocity/ nor an alternative object that would provide the current page (if there is any).

I assume a valid approach would be to accept the page ID and demand the client to use

$sitemeshPage.getProperty("page.pageId")

But this would be a backward compatibility issue for the clients of my app. Therefore, I would prefer a solution where the $sitemeshPage could still be passed as an argument.

Is there some documentation I am overlooking?

Hi @rr1

Could you please elaborate on what the issue you are facing is? What functionality/code of yours was working in 9.0 and is no longer in 9.1?

Hi @Kusal,

Thank you for looking into this!

We have a class we expose as an object for Velocity. This class has a method that accepts a parameter of type VelocitySitemeshPage.

In code that works with Confluence 9 (class (snip).MetaTagsGenerator):

import com.atlassian.confluence.util.profiling.VelocitySitemeshPage;
...
public String toHtml(final VelocitySitemeshPage sitemeshPage) {
  ...
}

atlassian-plugin.xml:

  <velocity-context-item
      key="velocity-static"
      context-key="projectdocContext"
      class="(snip).MetaTagsGenerator"/>
...
  <velocity-allowlist 
     key="projectdoc-velocity-allowlist" 
     name="Velocity Allowlist">
...
 
 <method>(snip).MetaTagsGenerator#toHtml(com.atlassian.confluence.util.profiling.VelocitySitemeshPage)</method>
...

The class seems to have moved to com.atlassian.confluence.impl.sitemesh.VelocitySitemeshPage. But I cannot get this to run on Confluence 9.1 (either because I add the lib to the OBR or because I do not).

The client used the context object in a Velocity Template like this:

#if ($projectdocContext)
 ${projectdocContext.toHtml($sitemeshPage)}
#end

$sitemeshPage is of type com.atlassian.confluence.util.profiling.VelocitySitemeshPage in Confluence prior to 9.1.0.

My questions are:

  1. What type replaces com.atlassian.confluence.util.profiling.VelocitySitemeshPage in Confluence 9.1.0?
  2. Or is using $sitemeshPage no longer supported?
1 Like

Hi @rr1

This does seem to be an unintended breaking change as the $sitemeshPage Velocity variable is now of type com.atlassian.confluence.impl.sitemesh.VelocitySitemeshPage which unlike its predecessor, is not OSGi available to vendors.

Let me check with my team and get back to you.

1 Like

@rr1

A quick workaround you may find acceptable for now is to change the method signature to:
public String toHtml(Object sitemeshPage)
And then use reflection to call VelocitySitemeshPage#getProperty

1 Like

Just following up on this - the $sitemeshPage Velocity context item was indeed not intended for marketplace vendor usage. I’d recommend calling #getProperty directly in Velocity, or use the reflection workaround if the former is impractical for your use case.

1 Like

@Kusal - can you shed any light on @rr1 's initial comment about com.atlassian.synchrony:synchrony-proxy:war:4.0.5 that seems to be missing from the Atlassian Maven repo?

As both @rr1 and @adam.labus have mentioned, this seems to be an issue when using AMPS 9.x and can be resolved by reverting to an earlier AMPS 8.x version.

In my case, I was successfully building using Confluence 9.0.1 and AMPS 9.1.1; but upgrading to Confluence 9.1.0 causes the error.

Is there another solution that doesn’t involve downgrading to an older AMPS version?

Hi @scottohara,

Thanks for reaching out.
There was some issue in synchrony-proxy artifact promotion to artifactory, I have manually promoted it for now, can you please check it works?
Meanwhile, we will sort out why the artifact promotion didn’t happen.
Thanks,
Ganesh

Unfortunately no, it doesn’t. (Unless I’m doing something wrong of course).

I ran atlas-clean && atlas-run and it gives me the same error.

If there are further steps I need to take, please advise.

It it helps, here is the properties section of my pom.xml

    <properties>
        <confluence.version>9.1.0</confluence.version>
        <confluence.data.version>9.1.0</confluence.data.version>
        <amps.version>9.1.1</amps.version>
        <atlassian.spring.scanner.version>3.0.3</atlassian.spring.scanner.version>
        <atlassian.plugin.key>${project.groupId}.${project.artifactId}</atlassian.plugin.key>
        <upm.license.compatibility.version>6.5.3</upm.license.compatibility.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>

Recall that the above config works fine if confluence.version is 9.0.1 or (according to others in this post) if amps.version is 8.17.2

Hi @Kusal, Thank you for the clarification! We’ll change our API and pass in the properties via #getProperty as suggested.

There is no other documentation on integration with Velocity for marketplace vendors than Confluence objects accessible from Velocity and we should only use objects listed there? I ask because if I use $sitemeshPage.getProperty("page.pageId") that object is not in that list.

Or am I missing something here?

Can the changes to the behavior of the websudo endpoint in 9.1 be described here?

I’m in the initial stages of troubleshooting a change that was detected by some integration tests. Our test renders a page that is under /admin (in the Confluence admin tools) and the test passes prior to 9.1 but breaks in 9.1 because the websudo authentication in the test is not working.

The test does a POST request to the doauthenticate.action. In 9.1 a subsequent request to a resource under /admin results in a redirect to login.action, indicating that the websudo authentication was unsuccessful or is not being seen in this subsequent request.

I noticed in Confluence 9.1 that the response to the POST request to doauthenticate.action (websudo auth) has a different JSESSIONID cookie value than the one included in the request. This is a change in behavior. Prior to Confuence 9.1 there was no JSESSIONID cookie value in the response from the websudo doauthenticate.action.

I am troubleshooting, trying to figure out exactly what is going on, so if anyone from Atlassian has some hints about what is different with the doauthentication.action request/response I’d appreciate it.

Thanks!

I guess the JSESSIONID is being rotated to deter session fixation/hijacking? I have not yet seen problems with websudo, although our CI has enabled the legacy authentication method.

That having been written, I have seen obscure authentication-related CI failures starting to appear only in 9.1+ that I have not been able to fully figure out. Even with -Datlassian.allow.insecure.url.parameter.login=true -Datlassian.authentication.legacy.mode=true, I see instances where a test drops out mid-session because the user gets kicked back to the login page.

The context is that a page is loaded and the user is logged in directly with a ?os_username=xxx&os_password=yyy query param. The authenticated page renders, but after a few hundred milliseconds, it is redirected and refreshed with the login.action page.

This seems to happen primarily when attempting to switch user authentication contexts in the same browser (ie. accessing a page as ?os_username=user1&... but then later reloading the page while authenticating as ?os_username=user2&...).

Selenium is not performing any actions during this time, so it is unclear as to what mechanism is forcing the refresh.

Here is a simple HTTP request flow that illustrates how changes in the behavior of websudo authentication in Confluence Data Center 9.1 are affecting my use-case.

We are authenticating using the websudo authentication endpoint at /doauthentication.action. Changes in 9.1 seem to have broken this flow:

  • On a Confluence Data Center instance with websudo enabled.

  • User is not logged in.

  • GET request to some resource that allows anonymous access, get a Cookie for JSESSIONID in the response

  • POST request to /doauthenticate.action (websudo auth)
    Cookie header uses JSESSIONID from previous request
    Authorization header for basic authentication for an admin user
    X-Atlassian-Token: no-check (to disable XSRF token validation)
    body: password=thepassword&authenticate=Confirm&destination=%2Fadmin

  • GET request to a resource under /admin
    Cookie header uses JSESSIONID from the websudo auth response (if present, like in Confluence 9.1) or the original JSESSIONID (if not present in the auth response, like in Confluence before 9.1)
    X-Atlassian-Token: no-check

  • Prior to 9.1 this GET request works (the response renders the admin resource). It does not work in 9.1 (the response redirects to login.action).

I don’t see any obvious way for me to modify this flow by modifying headers, etc. to make it work in 9.1. I’m hoping this flow description helps someone visualize what I am trying to do so that I can find out what to do in 9.1.

Thanks!

Just a quick update - I tried building again today with Confluence 9.1.0 and AMPS 9.1.1 and the error seems to have been resolved.

I’m guessing I just needed to wait a bit longer for the promoted sychrony-proxy artifact to propagate (or some intermediary cache to expire).

Anyway, all seems OK now. Thanks @ggautam.

2 Likes