This is a companion notice to the deprecation of the xdm_e and associated context parameters I posted previously. Thank you for your feedback there. This notice highlights the change in the nature of how apps should load all.js.
all.css in the same situation?
@david.pinn With the decision to retain the
xdm_e context parameter, we will continue to serve all.css from the host product, however all.js must be loaded from the connect-cdn
Hi @cmacneill and @dboyd,
We are in the process of making this change to our app. However, we are getting customer reports that our app is failing and it’s because of 404 errors loading all.js from the instance.
Was this change rolled out early to some instances? We are not seeing it fail in all instances
This is the response from Atlassian Support to our customer:
@jeff We have not rolled the change out at this time.
The message from support was given as the quickest solution to the problem of not being able to load all.js but we believe this is caused by a separate issue, specific to this tenant. I believe your organization support is involved in the support ticket. Could you please follow up there?
Thank you @cmacneill for your response. I have updated the support ticket. We will fix our app and will be releasing a fix for it very soon, but other vendor’s apps in this customer’s instance could be affected as well so I’m not totally agreeing with the support response.
If I got this right, all.js is not available even if you’re using atlassian-connect-express?
I think it depends on which atlassian-connect-express version you are still using. Newer versions than 3.5.something should work with all.js served from CDN out-of-the-box: https://bitbucket.org/atlassian/atlassian-connect-express/pull-requests/170/security-fix-update-update-hostscripturl