Last year, we published a blog regarding the development of our new site rename feature, including information on the impact of this feature on your Cloud apps.
The feature allows customers to rename their site from foo.atlassian.net to bar.atlassian.net. Since April, this feature has been available to customers via submitting a Support request. We action a site rename request based on the criteria that the ecosystem apps installed on a customer’s site are compatible with our feature
Over the past few months, we have been reaching out to vendors to verify the compatibility of their apps with our feature. This is an ongoing process and we have listed vendors who have confirmed with us on this public ticket here (CLOUD-10809 – Ecosystem vendors that are compatible with the Cloud Site Rename feature ). If you want to verify your apps’ compatibility with us, want to test the feature on your site or have questions, please reach out to us via here.
We are actively developing a self-serve option for customers and the site rename feature is expected to be available to customers via the Admin UI in the near future.
Concurrently, we are working on enabling customers to have custom domains. The custom domains feature enables customers to configure their Atlassian products to be accessible via a custom domain e.g. the customer can change the site URL from foo.atlassian.net to jira.foo.com. We’ll be engaging with vendors soon on the impact of this work.
I’m using Atlassian-Connect-Spring-Boot or Atlassian-Connect-Express, am I compatible with the feature?
If you are using the storage mechanism provided by Spring Boot and have not implemented your own storage layer, you will be compatible with the feature. All versions of spring-boot are compatible.
As an example you can have a look at this piece of code from Atlassian Connect Spring Boot: LifecycleController.java
As you can see whenever an ‘installed’ callback is received all the payload is used to update the record in database.
On top of updating the record you need to make sure that:
You don’t use the base URL as a primary key for any other table
You don’t store or leak the base URL somewhere else, and always read the base URL from the addon settings table (or equivalent) if needed
This answers the question for sprint boot, but not for ACE. Can you please confirm that native ACE use means we’re safe on the lifecycle side of things and only need to audit our own usage of base urls?
I caught this same thing before I published. I raised it with the team and am still waiting to hear back. However I didn’t want to hold up the comms. We’ll follow here and update the blog post when I get an answer.
I’ve finally confirmed with the team that ACE is also safe on the lifecycle side of things. The blog post has been updated to clarify ACE in the answer as well.
Hello, yes that’s correct. Our team is aware of this limitation and we are planning on implementing a solution to fix this. In the interim, you’ll need to re-create the access token.
In Atlassian-conenct-spring-boot, the information about the host product instance that performed the request, can be injected as a method parameter AtlassianHostUser . The AtlassianHostUser has a property to get base Url (URL prefix of the Atlassian product instance). We use this base Url for generating some links on the server side. Will this property reflect the updated value after the custom domain / site rename changes?
Also ACE - injects context variables into the rendering context which includes hostBaseUrl. Can you please confirm that the hostBaseUrl will contain the correct value after
after the custom domain / site rename changes?