I am having issues downloading the dependency com.atlassian.synchrony:synchrony-proxy:war:4.0.5 (absent) when starting Confluence with the Atlassian SDK.
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 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 …
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
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.
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.
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:
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.
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
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.
@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?
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
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.
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.
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.