I’m POC a new Confluence Connect App that requires access to a some Jira Rest API endpoints. As far as I know, there is no way for an App to do cross-product communication using the standard JWT security or JS Bridge. Is this true right?
So, I have been testing 3LO. The confluence App can request 3LO access to Jira via the authorization URL. The site admin can click on that URL and follow the authorization screen. Once the user accepts, the Confluence App will receive the access token to be used when talking to Jira.
At the moment I’m using the state query param to link the 3LO success callback to the Confluence App Client. But this is not reliable as the admin user may select another Jira host in the 3lo authorization screen.
Question: Is it possible to map a 3lo Cloud Id to an AC Client Key???
Regarding cross-product integrations in general, we have not yet provided any recommendations. Note that OAuth 2.0 authorization code grants (3LO) for apps only defines cloudId in the context of a single product, and that Atlassian customer sub-domains can be renamed.
I’m sorry that there is no way of doing cross-product communication. Is this in the pipeline? It seems like a pretty common feature. How can you create an “holistic” app/product/solution that works with both Jira and Confluence?
Would you provide a reliable way of linking a cloud id to an client key as workaround?
This is fine because my Confluence App would just need to talk to the Jira Product using 3LO. Confluence communication is done via standard AC
These are the following issue (missing Confluence Rest Api) that’s blocking us for carry on with the App. If you fix the following in Confluence I wouldn’t need the Jira communication.
Confluence rest get groups is no up to date after a group is created using Jira Rest api.
Options are wait for a few seconds, simulate that the groups has been created or to use JIRA 3LO
Jira and Confluence share the Group entities but only Jira is allowed to change them.
Please vote for AC-2001. We are aware of it, and we are looking at different platform improvements that would improve the situation.
I don’t see how that would help you. If you obtain the cloudId of the Jira selected in the 3LO flow, that particular cloudId only has a defined meaning in Jira, not in Confluence.
Providing these APIs seems like the ideal solution. Although it is perhaps more likely for the APIs to be exposed as product-independent APIs, see the section Cloud admin on https://developer.atlassian.com/cloud. You may want to raise feature requests against those APIs.
I have found a way to validate that the selected Jira instance in the 3LO authentication screen is the same host than the installed Confluence Addon.
Once the user accepts the 3LO screen and the addon receives the callback with the security token, the addon can call the https://api.atlassian.com/ex/jira/${cloudId}/rest/api/3/serverInfo and validate that the rest URL of that cloudId is the same than the installed confluence addon. If the user hasn’t selected the right Jira instance, the addon can reject that webhook callback staying “Hey, select the right host, the one with this BASE_URL!”
Unsure how the hostname renaming will affect Jira and Confluence. Could the hostname be different between products?
We have a separate eazyBI app for Confluence Cloud which allows publishing of reports from the eazyBI app for Jira Cloud as Confluence macros. Customers need to install both these apps in Confluence and Jira.
When we receive a request from Confluence site something.atlassian.net/wiki then by default we assume that the corresponding Jira site is something.atlassian.net (there is an advanced setting where a different Confluence site can be specified for a selected Jira site). We use the same user accountId and from our back-end server make corresponding requests to Jira REST APIs as the user with this accountId using JWT + OAuth user impersonation.
When I said that our documentation only defines cloudId in the context of a single product, I was suggesting that this kind of cross-product cloudId matching is currently at your own risk. It is not publicly documented API, and there is no guarantee that it will remain stable over time (for new customers).
@raimonds.simanovskis, I can see both of your apps in each marketplace. Thank you for the tip! The POC app is not big enough yet to justify 2 apps and 2 installations. I will definitely keep in mind your solution especially when doing User impersonation in cross product communication. 3LO would not support that.
@epehrson what would it be the official workaround? Is Raymond 2 apps the official solution? I guess I would need to wait for AC-2001
Like I wrote, Atlassian hasn’t provided any recommendations for cross-product integrations. Personally, I think eazyBI’s approach seems less risky long term, despite the additional complexity imposed by supporting site renames.
I have also found a strange behaviour in 3LO. For some reason the ‘code’ query parameter received in a authentication callback “references” to the wrong instance/cloudId. This is pretty odd.
By reference I mean, click on 3lo auth link → authorization screen → select one instance → callback with “code” received → get access token from that code → load Accessible Resources → the cloud id, the instance name, base url, etc are incorrect. The accessible resources method returns information about another instance I am admin. Are you aware of this issue? I’ve cleaned my app database and I still receive the wrong 3LO instance. If this is a bug, it may be pretty critical. A 3LO app may be talking to an instance that should not be talking to.
@fboucquez, I am not aware of any such issue with 3LO. From what I recall though, 3LO grants are additive, so if you go through the 3LO flow twice for a particular app and selected different sites, the call to Accessible Resources at the end of the second flow will include both sites.
I’d recommend you to raise a DEVHELP issue with the full details of the issue you have come across.