Hi everyone,
I am using atlassian-connect-spring-boot for my Jira cloud add-on.
When I am testing on my test cloud environment with the application deployed on a local server (localhost exposed with ngrok) everything works fine - I can install the add-on and then make jwt authenticated requests to the add-on app from the cloud.
Now I am creating a private app on the marketplace by providing the URL to the add-on descriptor.
I can open and see the descriptor in the browser.
In order to install a private app on a cloud instance you can’t pass the descriptor URL as it is - you need to use a dynamic URL generated by the market place for the specific add-on version you want to install.
So I am trying to install the add-on with the generated URL. I can open and see my descriptor using this URL, but when I try to install the add-on I am getting 401 Unauthorized error: “The add-on host returned HTTP response code 401 when we tried to contact it during installation. Please try again later or contact the add-on vendor.”
It seems to me that atlassian-connect-spring-boot is rejecting every request without the JWT token except the base URL to the descriptor, but in my case I need to use the dynamically generated descriptor URL for the installation, so I am getting 401.
As I said the URL is dynamic so I can’t find a way to overcome this problem.
Is there anyone facing the same issue?
Any ideas would be helpful.
Thanks!
Regards, Elitza Haltakova
Hi @ehaltakova,
the URL from which Jira retrieves your add-on descriptor should have no impact on the installation process. But the baseUrl field of your add-on descriptor needs to point to a URL at which your add-on service is publicly available.
Are there any relevant messages in your Spring application log? Perhaps one like this?
Installation request was not properly authenticated, but we have already installed the add-on for host [clientKey: …, baseUrl: …].
Cheers,
Einar
2 Likes
Hi Einar,
Thank you for the quick response!
You are right, I have previously installed the add-on so there was a row in the atlassian_host table. After I deleted the row, the add-on was installed correctly.
Anyway, I am not sure what actually causes this error and how to deal with it, because deleting the db is not OK for production scenario.
When I am testing locally I am using ngrok to expose my localhost on a specific port. The ngrok generates different URL each time so I need to re-install the add-on every time when the ngrok session ends up. I am installing the add-on on the same cloud instance so I have only one row in the atlassian_host table. In most of the cases I don’t get this error, but sometimes (rarely) I got the “Installation request was not properly authenticated, but we have already installed the add-on for host” message.
It would be very helpful if you can explain me when and why this happens some times but not every time.
Also, what can cause similar error on production - if a user installs the add-on from the market place (not by providing a URL) and then updates it, would it be working ok or should I take care somehow about providing the authentication details?
Thanks in advance!
Regards, Elitza Haltakova
The base URL of your add-on doesn’t matter in this context. You should notice no difference if you use the same URL consistently, or different ngrok URLs during development. But sure, if you change the base URL in your descriptor, you will need to reinstall the add-on to make sure that Jira has the latest version of your add-on descriptor.
Jira will use the add-on key to identify your add-on. Currently, as described on Authentication for apps, the first installation of a particular add-on for a certain Jira tenant will not be signed, since it serves to exchange an installations-specific shared secret, whereas following installation requests are signed.
There are some cases when a mismatch can occur - one side thinks that the installation was completed successfully, the other side does not. One example of that is when Jira times out before the add-on replies. You would be able to provoke that by setting a breakpoint.
You should normally never see this kind of error in production.
Please also see the article Moving away from per-installation shared secrets for apps on our developer blog.
1 Like
Okay, thanks for the detailed explanation and the useful links!
Regards, Elitza Haltakova
Hi, I have seen this kind of problems in production. I am not sure how this happened, but when we asked users, they mostly were saying that it happened after migration of their Jira instance from server to cloud.
Apps which were affected were based on atlassian-connect-express. For them, we could just delete row in database and next install was successful. However, for atlassian-connect-spring-boot it works differently, when a row is deleted from database, add-on fails to install.
I am wondering how can we solve such a problem when it occurs, without setting atlassian.connect.allow-reinstall-missing-host = true property. What would you do then?
How can we made Jira instance to send an unisigned install request, so we could store new credentials?
Is setting atlassian.connect.allow-reinstall-missing-host on production safe?
@maciej.dudziak, I wasn’t aware that atlassian-connect-express accepted signed first installs.
You could definitely set atlassian.connect.allow-reinstall-missing-host in production. I would recommend leaving that setting off in general, so that you can detect any shared secret mismatches. But you can definitely use it temporarily to solve a problem such as this.
1 Like
Ok, thank you @epehrson, I would do that.