RFC-35: Custom Domains Support For Confluence

General Request for Comments (RFC)
, ,
21

Hi @JohnHooper ,

We use the built in hbs in ACE to display links for users like:

<a class="aui-button aui-button-primary"
           href="{{ hostBaseUrl }}/plugins/servlet/ac/{{ addonKey }}/configure-page"  target="_blank">
          Click to check the configuration now</a>

I assume these links should use the displayUrl with custom domains.

In the frontend we also construct links like

hostBaseUrl + '/display/~' + encodeURIComponent(userRaw.accountId)

and the hostBaseUrl comes from the ACE backend.

Having the displayUrl available would allow us to display the correct links.

1 Like
22

Thanks @Chris_at_DigitalRose and @marc for the clarification.

The hostBaseUrl is derived from the iFrame xdm_e which is set to the domain which is rendering the site. In the circumstance of the Connect iFrame being loaded in a custom domain, this would then return the associated custom domain of the site. Similarly, if it is loaded on a *.atlassian.net site, it would provide the regular baseUrl.

23

Hi @SeanBourke ,
Thanks for the clarification. In the backend we also construct links similar to:

url: hostBaseUrl+ "/rest/api/content/{contentID}/property",

Will these still work with custom domains? I’m asking because now we need to access the API from the backend.

And a followup question: What will the ACE req.context contain? Will there be both a displayUrl and a hostBaseUrl?

1 Like
24

Hello,
I was testing the custom domain feature compatibility with our app. Our iframes aren’t loading and I’m getting this error on the console, related to the all.js:

Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://old.subdomain.url.atlassian.net’) does not match the recipient window’s origin (‘https://new.custom.domain’).
(anonymous) @ all.js:94
R @ all.js:276
(anonymous) @ all.js:278
(anonymous) @ all.js:278

Any idea? @JohnHooper

Best,
Paulo Alves.

25

@PRPA that looks easy to diagnose. The post message communication between your app and Confluence is targeting the wrong domain, so the messages never get through. Atlassian will have to fix this. Maybe open an ECOHELP or other support ticket.

1 Like
26

Thanks David, but I just want to prevent this from happening to our customers.
Do you know if Atlassian is going to fix this problem?

27

@PRPA I’ve opened ECOHELPPUB-114 for you and marked it as public.

I have no idea whether this will help.

Cc: @JohnHooper

1 Like
28

Thank you David!

29

Hi,
How should we handle the “whitelist” option in the config.json file for the Atlassian Connect Express framework?

If we leave the option at its default setting, installations from custom domains are rejected as they are not allowed. The only alternative I can think of is to add a rule to the allowlist that permits installations from any domain. However, this ultimately renders the option and the inherent security mechanism useless.

Is there an official position from the Atlassian team that we should follow on this?

2 Likes
30

Hey @alessandrodistefano,

All installation, webhook, etc. requests should still come from the existing baseUrl (as in *.atlassian.net), not from the custom domain. This means that existing whitelist options should permit these requests as expected.

If you’re seeing something different to this, please let us know and we’ll look into it.

31

Thanks everyone for your feedback regarding Connect, a few additional updates:

  • We are working on some updates to ACE and ACSB which will result in the displayUrl and displayUrlServicedeskHelpCenter being persisted for both Confluence and Jira custom domains.
  • We are working on extending AP.context.getContext() to also return the displayUrl and displayUrlServicedeskHelpCenter for Confluence and Jira front-end only apps.
2 Likes
32

We ran tests on an instance with a custom domain, and we couldn’t install a connect app due to the block applied by the whitelist option. Only by applying permissive rules (e.g. unblocking installation from any domain) were we able to get the installation through.
I recommend conducting a thorough review of this aspect; otherwise, there’s a risk that all customers with an active custom domain won’t be able to install many of the apps available on the marketplace.

33

Hey @PRPA and @alessandrodistefano,

It looks like some features weren’t yet enabled for your EAP domains. We’ve now enabled fixes for Connect Confluence custom domains for all EAP domains and you should no longer experience these problems. If you run into any issues, please share your instance’s domain via a DM and I’ll follow up to confirm everything is enabled as expected.

3 Likes
34

Here’s what I see so far. Something doesn’t seem quite right and it is not particularly usable:

  1. There are no HTTP redirects from the old xxxxx.atlassian.net site to the custom domain.
  2. If you attempt to access the site from the old atlassian.net domain anyway, loading something from a Connect app configured as “target”: “dialog” produces HTTP 403 errors.
  3. No lifecycle hooks are sent to the app when the custom domain is enabled.
  4. No lifecycle hooks are sent to the app when the custom domain is DISabled.
  5. Every time I deactivate the domain in admin.atlassian.com, I receive a new email with subject line: “Custom domain is ready to activate”.
  6. Once you start using the new custom domain, you can navigate to the /jira URL and start using JSW on the custom domain too. Are JSW app vendors aware of this?
  7. When using the site from the new custom domain, we see failed requests from our back end for Connect user impersonation. The Confluence host returns: HTTP 403 “Session auth token failed secret validation”.
  8. The Connect lifecycle install/uninstall/enable/disable payload supplies the custom domain URL for both the baseUrl and the displayUrl.
  9. I can’t install a new app after the custom domain is enabled, due to the whitelist issue. ACE is causing our app to return HTTP 401 to the install request:
    Installation verification error: 401 Host at https://mycustomdomain.com/wiki is not authorized to register as the host does not match the registration whitelist (*.jira-dev.com,*.atlassian.net,*.atlassian.com,*.jira.com).
2 Likes
35

As an aside, this RFC is marked as having the discussion closing today. I don’t know if anyone else is in this situation, but I filed a ticket to participate in the EAP as soon as the program opened, but the custom domain on my test site did not get enrolled in the EAP until two days ago. (And I am still limited in the feedback I can provide because so many things seem to be broken, at least on my test site, as in my post above.)

Since other people may be in the same situation, perhaps you might think about extending the RFC period so that more people can actually experience the custom domains and provide feedback.

36

I registered on the EAP within minutes. Im still waiting for the custom domain to start working. I added the name records a few days ago, after receiving the “custom domain is ready” email.

I hope it’s not as bad as @scott.dudley says :crossed_fingers:

37

Thank you @scott.dudley for sharing all of the items you’ve uncovered.

And yes, that’s a fair point on extending the RFC period. As of now, we’ll add an additional 2 weeks to the original timeline

1 Like
38

@JohnHooper We’re now waiting about a month to be enrolled into the EAP.
Are there any blockers?

39

Hi @marc - we have encountered some items that we’ll be resolving over the next few months before the feature’s GA, but no blockers of the GA yet