Connect data residency with single compute region

Jira Development Jira Cloud
, , , ,
1

Hello everyone,

We’re trying to update our Connect app to support data residency, and encountered a major blocker, so I’d like to ask if anyone else experienced the same, and maybe found a solution?

We have a project based on Atlassian Connect Spring Boot, and would like to have a single frontend (compute region) for the app, which handles storing data to multiple regions, based on where the app was pinned by the customer.

So far, I’ve asked Atlassian if there’s any REST API to get the current region, and they said that the only way to get that is to have a different domain name for every region of your app, so I’ve created multiple domain names pointing to the same hosted frontend, not ideal, but so far so good.

However, when the ACSB library tries to validate the JWT tokens sent by Atlassian, it always reads the baseUrl from the atlassian-connect.json file, and doesn’t accept any of the other urls that are listed in the regionBaseUrls.
And it’s not just validating the JWT that causes issues, the whole project seems to use the baseUrl as the one and only canonical url of the app, which causes further problems down the line: even the logic that determines whether the current request is an install request or not, fails to do so, because the url doesn’t match.

My question for everyone reading this:
Did anyone try to handle data residency with a single frontend?
If so, did you encounter this issue? How did you solve it?
Did I miss something in the documentation, or is this really so hard to implement with the current tooling?

I see that the Atlassian Connect Express library has an allowedBaseUrls configuration, which accepts a list, so it might help with this scenario, but it doesn’t seem to exist in the Spring Boot version, and rewriting is not feasible for us.

Any and all feedback or help would be appreciated.

Thanks.

2

There is a hacky workaround to identify the base product region using the “HTML API” (I presented it in a lighting talk in the latest App Week).

Make anonymous request to https://{site}.atlassian.net/plugins/servlet/ac/foo/bar and in the HTML response find <meta name="ajs-region" content="..."> which contains the region where the base product is located (e.g. prod-west2 or prod-euwest or similar).

BTW we are also thinking about a similar solution to have some computing and data storage resources centralized and some decentralized to several data residency regions and having a single baseURL in the descriptor. But in our case we plan to provide customers the option to migrate their data to selected data residency region instead of automatically detecting it.

Kind regards,
Raimonds

1 Like
3

I’m glad to hear we’re not alone with this idea!

The mentioned hack wouldn’t work for an install hook though, right?
And does it return the region of the host product, or the region where the app is pinned?
As far as I know, the product migration and the app migrations are handled separately. (but I might be wrong about this.)
We would like to store all at-rest data to the respective region, including the installation info.

Oh and of course we want to provide the customers the option to select their region as well, sorry if that was not clear from my post.
We already have a PoC for implementing the dare-migration lifecycle hook to handle moving data when the app is pinned to a different location.

Having 1 url for all locations would most likely fix the issues we currently have with ACSB, but it would also mean we would have to use this HTML hack for every incoming request, which doesn’t seem ideal.

Using a different url for every location would allow us to get the region info from the request url, which is much faster, and should be less likely to break, that’s why we went to this direction, but it looks like ACSB doesn’t handle this use-case as of now.

For anyone who might also be affected: I opened a feature request in ACSB here: [ACSPRING-182] - Ecosystem Jira

4

From a customer point of view, I believe this workaround does not look like data residency. While data at rest is in different regions, transferring it for compute is what probably surprises customers.

5

As far as I know, processing data in the specified region is by no means a hard-requirement, this is usually more lax in terms of compliance too.

Even Atlassian doesn’t seem to make any guarantee regarding in-flight data, and they have quite a lot of exceptions for at-rest data as well.
We plan to have ALL our at-rest data in the specified region, so that’s already better than what the host product does.