Deprecation of xdm_e Usage

Summary

Prior to the introduction of the cacheable iframes pattern, the location of all.js was only provided to apps relative to the tenant base URL. This meant that app pages had to determine the URL of all.js using a scheme that incorporated parameters xdm_e and cp which were passed to the app in query parameters. These parameters are not passed into cacheable iframes, so all.js is now available from the following URL:

https://connect-cdn.atl-paas.net/all.js

Loading all.js from the xdm_e parameter is being deprecated, and vendors are now required to load all.js from the connect-cdn. The xdm_e parameter will be removed as of 01 Feb 2020.

Update

We’ve recently released a deprecation update for Atlassian Connect Express, Atlassian Connect Express project templates, and Atlassian Connect Spring Boot. If you haven’t updated your version, please update to the latest version or at least on version 3.5.2 for Atlassian Connect Express, or 2.0.1 for Atlassian Connect Spring Boot.

How to update to latest version of Atlassian Connect Express?
  1. Open a terminal
  2. Go to your app’s root directory
  3. Type the following in command and that should update package.json and install the latest version of atlassian-connect-express dependency in your app

npm install atlassian-connect-express@* --save

Version 3.5.2 or later will load the Atlassian Connect JavaScript library (all.js) from its CDN location.

How to update to latest version of Atlassian Connect Spring Boot?

Typically the version of the Atlassian Connect Spring Boot is declared in a Maven property in your project POM

<atlassian-connect-spring-boot.version>2.0.1</atlassian-connect-spring-boot.version>

This is then referenced by multiple Maven dependencies:

        <dependency>
            <groupId>com.atlassian.connect</groupId>
            <artifactId>atlassian-connect-spring-boot-starter</artifactId>
            <version>${atlassian-connect-spring-boot.version}</version>
        </dependency>
        <dependency>
            <groupId>com.atlassian.connect</groupId>
            <artifactId>atlassian-connect-spring-boot-jpa-starter</artifactId>
            <version>${atlassian-connect-spring-boot.version}</version>
        </dependency>

Version 2.0.1 or later will load all.js from the Atlassian CDN

8 Likes

For the web-items that are pointing out of the iframes (ie the redirect servlet) - what is the recommended replacement? The only alternative I can think off is to decode the jwt to get the clientKey and then request the base url from the instance information end point. I haven’t figured out how to handle the case where the jwt is invalid (ie expired).

Any suggestions would be appreciated.

1 Like

You could use JS API getLocation method to get the current host product page URL (https://instance.atlassian.net/browse/SMART-115) and then extract host base URL from it.
However, it will add some latency to UI.

AP.getLocation(function(location){
  alert(location);
});

Unfortunately if I’m using a web-item that points out of the Atlassian app experience - I don’t have the AP bridge (since I no longer in an iframe experience) so that won’t work…

/Daniel

@daniel Just confirming, you’re referring to a web item with context: addon that re-directs the user to a URL relative to the add-on’s base URL?

… and then you’re using the xdm_e parameter to know which tenant the user clicked through from?

If so, thanks for letting us know. We’ll discuss this use case, and provide an update soon …

1 Like

Yepp. That’s the use case.

I just caught this part:

Since there hasn’t been a deprecation or change notice about this requirement (I just looked at https://developer.atlassian.com/cloud/jira/platform/ ). Can this be called out more please since I’m pretty certain that there vendors/developers that will be surprised in Feb 2020 when things start breaking for them. @nmansilla @mpaisley @rwhitbeck

In the mean time I’ll just wait on @dboyd to solve my original question… :wink:

Hi,
Can we also safely assume that the base URL for all Confluence instances will have a path like this:

https://www.somedomain.atlassian.net/wiki

Till now we used to compose the base URL in this way:

baseURL = xdm_e + (cp ? cp : “”)

Hi @cmacneill

We noticed that sometimes the CDN fails to serve all.js file (in < 0,1% page loads). Could we put the all.js file locally and serve it from our app? We can update it from time to time.

Thanks. I will prepare a separate, explicit note highlighting this aspect.

The CDN shouldn’t be failing (it’s just linking to a static file hosted on amazon cloudfront). Can you please give some insight into the 0.1% claim? You may have a user with some sort of browser plugin that is blocking the script from being loaded - this is far more likely than cloudfront being down.

We can’t stop you hosting the file yourself but it’s not something I can support. It may also update at any time with breaking changes as we assume the file is always being served from us.

Hi @cwhittington,

Our app loads the script synchronously. We registered a diagnostic function as an “onload” handler for the script, and our Sentry reports that it doesn’t call sometimes.

We also added a diagnostic which checks whether “onload” was called, and if not, it tries to get the script using Axios. It always works with Axios.

Please let me know what kind of diagnostic we can provide you to reproduce the problem.

I can relate to the problems with all.js not loading. We have an onerror handler which now fires more frequently since we’ve switched to load all.js from the CDN.

We’ll probably implement a retry logic in our script loading or otherwise show an error to the user if all.js cannot be loaded. Please let me know if there are any other suggested workarounds.

Hi @cmacneill,
will only the parameters xdm_e and cp be removed?
will the rest of the parameters not be removed (issueKey, cv, lic, xdm_c…)?

1 Like

@davidrtz , correct. We are only looking at xdm_e and cp. Other parameters are unaffected by this notice.

We are also considering the issues raised by Daniel for xdm_e usecases beyond loading the Javascript API. Whilst these are outside the original intention behind providing xdm_e we do see the validity. I will provide an update here shortly.

1 Like