My goal is to send an HTTP request from my Jira connect app (using ACE) to the Confluence API. I’ve been getting a 401 error so I know I need to generate a proper JWT for authorization but I have had some trouble accessing the sharedSecret which seems necessary for this process. I can get my clientKey just fine from the request context and I know the sharedSecret is being stored in the in-memory db. Is there an object that the sharedSecret lives in or can anyone point me in the right direction for sifting into the :memory: db to extract this? And if this is an unnecessary plan of action for the goal of sending a get request from my connect app please let me know that too! Thanks in advance!
I’m not familiar with ACE but normally you would get the shared secret as party of the postinstall script payload. I assume ACE also includes handlers for this event, which should allow you to access this information.
Okay thanks, yeah I have found their handler in the ACE source code but have been trying to really figure out how to interface with the data. However, I think my issue actually may be related to trying to access the Confluence api from a Jira addon. I found that I can hit the Jira api and have access without the need for all this. I had assumed the Confluence api would operate under the same rules and be accessible from both domains since they live at the same base url (with the /wiki difference) but now I’m not so sure about that…
Just for reference, the easiest way to make a REST request to the host product is by getting an http.client from the addon object:
var httpClient = addon.httpClient(req);
httpClient.get('/', function(err, res, body) {
...
});
(See here: Bitbucket)
That being said, I’m afraid you’re correct in that your addon either is a Jira or a Confluence addon and hence you will most likely need to manually authenticate with the other tool.
2 Likes
Okay thanks! What exactly do you mean by manually authenticate with the other tool? Does that mean generating a JWT like I was planning to do earlier? Requiring a shared secret? Or will this still lead me to a 401.
Yes, I was referring to your earlier plan, building your own JWT for authorisation, but I guess things will be a bit more complicated as you cannot reuse the shared secret that is established between Jira and your app.
However, the Confluence Cloud REST API has some options for auth, as listed here:
https://developer.atlassian.com/cloud/confluence/rest/#auth
I have no experience with these, so I cannot make any recommendation here.
1 Like
So from looking at this ticket How to access confluence REST API from JIRA addon? could I just make 2 separate apps and then pass the response data between them? Shouldn’t I be able to bypass auth between them if I just directly pass the info from the confluence app to the jira app via the server they live on?
1 Like
Sure, if both apps live on the same server (or have other means of communication), I see no reason why that wouldn’t work. Thinking about it, I’d put a queue of some sorts between them and let them pass any requests to their sibling, so that I would not need to pass the auth info at all. That would also save you from having to handle the JWT yourself.
Downside is, you’re writing and installing two apps. If that’s ok with you, I’d say you found a good solution for your problem 
2 Likes
I’m currently in the same situation. I’m trying to create a JWT token in order to make calls from a Confluence Cloud connect app to Jira cloud rest API. According to de documentation, this is possible by implementing 3LO.
So I tried to create a new JWT token for user impersonation based on this documentation:
https://developer.atlassian.com/cloud/jira/platform/user-impersonation-for-connect-apps/
It stated that “oauthClientId” is needed for “iss” (issuer), but how does one get this property?
I can see this property listed after sucessfully running “nvm start” to install the app.
It’s also not clear wether this solution supports authentication and rest API calls between Atlassian cloud products.