Deprecation of xdm_e Usage

Announcements
, , , ,
1
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.

all.js will no longer be available from the instance as of 01 Feb 2020.

Imminent Deprecation

As the deprecation date for this change is now imminent, we require apps to move from loading all.js from the host product instance to loading from the CDN, as we have indicated.

If you are using the Atlassian provided frameworks, ACE or Connect SpringBoot, the simplest method to make that change is to update to the latest versions of these frameworks.

If you are using your own code, you should be following the instructions for all.js at https://developer.atlassian.com/cloud/jira/platform/about-the-javascript-api/#javascript-client-library

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

9 Likes
2

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.

2 Likes
3

You could use JS API getLocation method to get the current host product page URL (Log in with Atlassian account) and then extract host base URL from it.
However, it will add some latency to UI.

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

image
image2560Ă—1472 442 KB

4

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

5

@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
6

Yepp. That’s the use case.

7

I just caught this part:

Since there hasn’t been a deprecation or change notice about this requirement (I just looked at Jira Cloud 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:

1 Like
8

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 : “”)

10

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.

11

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

12

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.

13

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.

14

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.

15

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
16

@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.

2 Likes
17

Hey @cmacneill,
Any update on this? We also use the baseURL value which we extract via the xdm_e parameter.

4 Likes
18

Hi @cmacneill

Any news here, There is more than a 1 month since you promised to post an update shortly.

We are really worried that there is not much time left till 01.Feb.2020

1 Like
19

My apologies for the tardy update.

We have considered the issues raised by Daniel Wester. To support such use-cases, we have decided to retain these context parameters. We will, however, proceed with the removal of all.js from the host product and require it to be loaded from the connect-cdn as described here: Deprecation: Javascript API, all.js, must be loaded from Connect CDN - #2 by david.pinn

All apps using the xdm_e value should ensure it is a valid value by verifying the query string hash value qsh.

2 Likes
20

Hi @cmacneill,
excuse me, what do you mean by “verifying the query string hash value qsh”?

1 Like
21

Qsh is an attribute sent in the jwt token - it’s a checksum that allows you to validate that the url that you’re receiving is sent from atlassian.