Hi,
I try to develop an app using Atlassian Connect. One thing is still unclear to me - how do I store security context for my app?
I have a basic app, with atlassian-connect.json, its all ok. The app is installed to our test env. This guide (Authentication for apps) states that “When an administrator installs the app in an Atlassian cloud instance, Connect initiates an “installation handshake”: it invokes the endpoint, passing a security context. You must then store this security context for future use.” How do I store this security context?
Does this mean that “/installed” endpoint should be a POST method endpoint waiting for the “handshake”? Because as of now, there is no “/installed” endpoint created by me (I suppose it is implicitly created by Connect?) and the app has been sucessfully installed.
We cannot use Jira REST API yet as the JWT is not created, because I dont know how to get the “secret” from installation handshake.
Many thanks for a little push with reading the security context from installation handshake
BR /Adam
Are you using one of the two Atlassian Connect Frameworks (Spring Boot or Express)? If yes, this is handled automatically for you. If you’re building your own custom solution you’ll need to implement life cycle endpoints by yourself.
Hi Sven,
thank you for the explanation. Yes, I use Spring Boot.
There comes one more question - how do I know the URL of Jira Cloud instance that the app has been installed to? Say MyApp is installed to JiraCloudABC, and the security context is provided in installation handshake. My app wants to read all issues in JiraCloudABC, where do I find the URL of JiraCloudABC to send the REST request to?
My first thought were to read the details from installation handshake and store every Jira Cloud instance details that the app is installed to, but now it seems the logic is a bit different. Could you please advise?
The baseUrl is part of the installation payload and will be stored in the ATLASSIAN_HOST table. You can inject the AtlassianHostRepository into your Components to get AtlassianHost objects out of your database.
But unless you have some kind of scheduled job where you need to get all issues independently of a user request, you’ll probably want to get a @AuthenticationPrincipal AtlassianHostUser user injected into your Controller methods and get the host via the user object.
Hello Sven,
now I have the app running and communicating correctly with Jira Cloud instance.
My last question is - for some reason my app on /rest/api/3/project? endpoint gets an empty array, but using same URL in Google Postman I receive an array populated with all available projects as expected. Do I miss some settings somewhere?
Sorry for hijacking the topic, but I guess my question would be usefull for you too.
What is the best practice to verify the first install request is actually comming from atlassian and not a malcious user that just POSTs junk security tokens that will be stored in your database?
You can’t really. This is an open hole in Connect’s installation handshake and is not handled by the two official frameworks either.
If you want to take action on your own, you could work with an IP allowlist or try to validate the token shortly after install. Note that this cannot be done right after installation though, as it can take a variable amount of time before your apps authentication will be accepted. But I’m not sure if theres’s many apps that do this in practice, i.e. I don’t really believe this is necessary.
What’s probably more viable is to have some kind of scheduled clean up mechanism that throws out old (and invalid) data after a given timeframe. Depending on what else you store, you might want to have something like this anyway due to GDPR.
Just as a general note here: although cleanup is super duper important, if you’re not storing PII, GDPR will not require you to do so. And you should avoid storing PII at all cost.
