Hello,
developing a confluence app, i need to get some information from jira, so I have to call jira api from my confluence app, but I don’t know what is the best way to do that.
Do you have any ideas plz ?
If I have to use a standard httpClient , how can I get the login and password from credentials.json file ?
thank you
1 Like
Look at ApplicationLinkService from “com.atlassian.applinks.api.”
Then you will be able to get list of applinks configured, find the Jira one and do something like
final ApplicationLinkRequestFactory requestFactory = appLink.createAuthenticatedRequestFactory();
So, all the communication will be through an applink abstraction (authentication and so on)
Alex
Hi @sash011,
Your suggestion seemed server oriented. Any experience in cloud/connect environment with Jira to Confluence linking?
SN
Through PAT tokens.
So the user needs to provide a PAT token for app to use to access Jira.
Dont know any better way, sorry
@anon13613963 and @szn,
I’m a Partner Engineer at Atlassian, so I work with SaaS vendors that need to cross security boundaries, just like you are trying to do between Confluence and Jira. While there are Connect Apps that do it, it isn’t easy. And I am not aware of any docs that explain how to cross product boundaries.
Any experience in cloud/connect environment with Jira to Confluence linking?
With a Connect App, you need the same App installed into both Confluence and Jira so the App can use JWT authentication for each API. In a way, this is like a class that implements 2 interfaces and has some shared state between the 2 interfaces.
how can I get the login and password from credentials.json file ?
You can’t. And the “10th commandment” of Security requirements says, " The application must not collect Atlassian user credentials." That means API calls made to Jira should be done with the same mechanisms as Confluence but using a different security context (still JWT but different shared secret).
That’s a broad, architectural “how” but if you need more details, I would need more context too.
1 Like
Thanks @sash011,
That sounds interesting. Sadly, PAT works only with Data Center and server editions. I am looking for a Cloud compatible solution. I am connecting from Confluence to Jira using oauth. But this is very annoying for users (they have to authorise my plugin).
SN
Hi @ibuchanan,
Thank you very much for this suggestion. I was experimenting with the idea you suggested around Dec 2020 but I gave up.
My plugin (Smart Issue for Confluence) actually allows users to interact with Jira issues directly on a Confluence page. I used OAuth and it took me weeks to make this connection working.
Oauth is unfortunately annoying for users as each of them have to authorise the plugin by themselves. This problem is mostly accepted by my users but the upcoming one month rotation of refresh-tokens is a big problem for me (users will have to reauthorise the plugin monthly).
I have one question and one (hopefully small) request:
- Can the solution you described work against cloud instances of Jira and Confluence?
- If so, can you please elaborate a little bit more about this?
Regarding the 2nd point:
I understand I have to add separate descriptor to my app (Jira version) and keep track of installations (to make sure that each Confluence installation has a corresponding Jira installation).
As far as I understand I can not publish a jira+confluence compatible app in the marketplace, so two separate listing will be visible (for ex: “Smart Issue” and “Smart Issue Jira Connector”).
Then, while users sends request to “Smart Issue”, I should take his/her JWT and send request to Jira?
Should I use regular Jira API (under ___.atlassian.net) or the one under api.atlassian.com/ex/jira?
All hints are welcome and highly appreciated.
Best,
SN
To follow up on @ibuchanan ‘s suggestions. You’ll need to create a second app to be installed in Jira. Between that app and your confluence app you’ll need to set up a handshake for the admins to do (you can do this using the admin pages).
Once you have that set up - you can request the jira data from your confluence app through the Jira app.
Of course once you start doing this - you’ll need to come up with your own security token scheme between your confluence app and your Jira app.
1 Like
Before we try a different solution, maybe there is some misunderstanding about rotating refresh tokens. What you describe here is not the intent and shouldn’t be necessary in implementation. If at all possible, I think it would be better for you and your app to stick with OAuth.
As with persistent refresh tokens, you must use the scope offline_access when you request authorization the first time and that will cause the /oauth/token endpoint to return the first refresh_token in the payload.
{
"access_token": "...",
"refresh_token": "first-refresh-token",
"scope": "offline_access ...",
"expires_in": 3600,
"token_type": "Bearer"
}
For the first 3600 seconds (15 mins), I can use the access_token. After that, I’m going to need to exchange the first-refresh-token for a new access_token. For the sake of example, let’s say I need it right away at the 15 min mark when the access token expires. When I do that, the response is pretty much identical, with new tokens.
{
"access_token": "...",
"refresh_token": "next-refresh-token",
"scope": "offline_access ...",
"expires_in": 3600,
"token_type": "Bearer"
}
However, two things are critical at this point in the flow. First, first-refresh-token is now “used up”. I can’t call /oauth/token with it again, else I do void the authorization grant and I have to start all over again. If I did that, it would force users to reauthorize every 30 minutes, not every 30 days. So be sure not to reuse the refresh tokens.
Second, next-refresh-token has a 30 day lifespan starting now; 15 mins later than first-refresh-token. My refresh token is refreshed. And, if I keep exchanging the refresh token within it’s lifespan, I keep getting a new one for the next 30 days. With active usage of your app, there should not be a need to reauthorize monthly.
You are correct when the users don’t use the app for 30 days. Then you don’t have any way to hold on to a valid authorization. As such, your app must reauthorize.
Before I return to your questions about Connect & JWT, could we exhaust the OAuth option? Is there a reason something in the flow above won’t work for your App? Or is it the last case, where users reauthorize because they don’t use it for 30 days?
Thank you @ibuchanan for the detailed explanation.
I know that the validity of the refresh_token is extended each time a user uses it to request a new access_token. I have this option (Use rotating refresh tokens) already enabled in my staging environment. This adds one more layer of complexity on top of my existing OAuth implementation ;).
I am not expecting my ‘power-users’ to actually face one-month breaks. But the content they create can be accessed by random people in the organisation. These users are very likely to face the “You need to authorise the plugin” problem.
More importantly, the need to authorise the plugin is annoying despite currently lifetime refresh tokens. From a user perspective, Jira and Confluence are part of the same ecosystem. Why should they authorise if the link between these two is already set up?
To wrap up: I am still interested in using a bridge/link and bypass OAuth.
Following up on what @danielwester wrote:
Does this mean that the ‘Jira app’ will connect to the ‘Jira instance’ as ‘app’ (or service-account to use cloud naming)? So actually these two apps will create a bridge between two instances?
(possibly it’s a silly question, but I am deep in OAuth way of thinking so the above is not clear for me)
Pretty much. You can come up with some fancy handshakes for the admins to handle (and then also extend it to multiple Jiras and multiple Confluence) since you can pass query params through the admin page module.
But in the end - the Jira app talks to Jira. Confluence app talks to Confluence and in between - that’s between them. However and I can’t stress this - you have to come up with your own token/security between the apps.
/Daniel
1 Like