Deprecation notice: Loading Connect stylesheets from CDN instead of inline

Announcements
, , , , ,
1

Hi developer community, we just announced the deprecation of Atlassian Connect JS loading stylesheets via inline styles, to loading them from the same Connect CDN that all.js is loaded from.

To clarify, this change affects how Atlassian code loads styles internally, and does not prevent your app from using inline styles. However, this will affect your app if you are utilising a Content Security Policy.

This affects the Theming API, and dynamic content macros that supported the legacy Confluence editor.

At the end of the deprecation period (November 18, 2024), we will stop injecting any inline styles and only load from the CDN. If you haven’t allowed loading the styles from the CDN by this point, then theming will no longer work correctly in your app.

If your app doesn’t use the above Connect features, or does not use a Content Security Policy for style-src, no action is required.

Otherwise, please keep reading, or check out Security requirements for cloud apps for details on how to modify your CSP to support these changes.

Action required

To support these changes in your app, if you’re using a Content Security Policy that sets the style-src policy, you must add the Connect CDN (https://connect-cdn.atl-paas.net) to your policy to allow these stylesheets to be injected.

This change means you will no longer be required to use unsafe-inline, and so it’s safe to remove this from your policy if you’ve been relying on it up until now.

Additional context

The stylesheets mentioned here are included automatically via the Connect JS script, not manually by the app vendor. There are two circumstances under which Connect injects stylesheets into your app.

The first is only for apps which opted in to the Theming API. The theme stylesheets currently load via an inline stylesheet, which forces vendors to adopt the insecure unsafe-inline policy, and is the main motivation for this change.

The second location is only for dynamic content macros. We inject a stylesheet with CSS classes representing colors from the legacy Confluence editor. This happens without opt-in, to be backwards-compatible with macros created in the legacy editor. This injection is currently done via CSSOM, not inline styles, and therefore isn’t impacted by style-src CSP rules currently. However it’ll also start being served from the CDN at the end of the deprecation period.

During the deprecation period, styles will be loaded simultaneously via the current methods described above and from the CDN. After the deprecation period, styles will only be loaded from the CDN, and the inline/CSSOM methods will be removed.

5 Likes
2

Hi @SamLeatherdale ,
We’ve applied the CSP as instructed in your post and in the changelog.
However we believe that the issue is NOT resolved:

Chrome error:

all.js:193 Refused to apply inline style because it violates
 the following Content Security Policy directive:
 "style-src 'self' https://connect-cdn.atl-paas.net".
 Either the 'unsafe-inline' keyword, a hash ('sha256-Sv2wisYI2b4kI6wUy5UrkVe+CrkucJm2osG/Ov1Jhw='),
 or a nonce ('nonce-...') is required to enable inline execution.

Firefox error:

Content-Security-Policy: The page’s settings blocked an inline style
 (style-src-elem) from being applied because it violates the following
 directive:
 “style-src 'self' https://connect-cdn.atl-paas.net”
 all.js:193:386

This error is caused by all.js, which is loaded from the Atlassian CDN.

Can you please have a look and correct the issue?

1 Like
3

Hi @marc

Thanks for pointing this out.

This behaviour is expected. During the deprecation period, we are attempting to load the stylesheet inline, for apps that haven’t yet added the CDN to their CSP, and also from the CDN for those that are adopting it early.

At the end of the deprecation period, we will stop attempting to load the stylesheet inline. Until then, you can safely ignore this warning.

Can you confirm that the stylesheet from the CDN is loading and applying correctly?

4

Hi @SamLeatherdale ,
Thanks for the reply. We can confirm that the styles are loaded and applied.

However the CSP warning is raised in our customers browsers, and we can’t control this CSP error. Having CSP errors in our app is a problem.

Is it possible that Atlassian applies conditional loading to all.js, depending on the CSP policy? This could be done by e.g. having 2 versions of all.js.

5

Hi @marc

We did investigate all possible options to try and avoid this. There is unfortunately no way to detect whether a given CSP is active without triggering it and displaying the warning. There is a SecurityPolicyViolationEvent that is raised, however this does not allow us to suppress the warning.

Providing a separate copy of all.js, or modifying the API to load the styles, is not something that we’re keen to do, to minimise the amount of work required for developers to support these changes. We do want to reiterate that this is a warning and not an error, i.e. it will not throw an exception and prevent your app from continuing to run.

As for warnings appearing in the user’s console, while far from ideal, there is a large volume of warnings already generated by Atlassian products in the browser console. Do you ask your users to search for warnings coming specifically from your app’s iframe when providing error reports? (In this case, it’s true that the CSP violation warning will come from your app’s iframe).

Unfortunately I don’t think there is a simple solution we can provide for this issue. If you are getting a large volume of users confused by this message, you could listen to the SecurityPolicyViolationEvent in your app, and log out your own message to the console, similarly to how we do when we detect our CDN has been blocked:

CSP violation detected for style-src in app <example>
Please add https://connect-cdn.atl-paas.net to your security policy for script-src and style-src.
See https://developer.atlassian.com/platform/marketplace/security-requirements/#connect-apps for details.

6

Hi @SamLeatherdale ,

Thank you for the explanation.
We’ll try to work around the issue. I hope that Firefox or Chrome do not get stricter until the deprecation date.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.