Hello everyone. When I try to develop an Atlassian cloud add-on using ACE and Node.js on my local machine it works perfectly. The add-on is connected to the cloud instance and the output is as expected (the add-on works properly), but when I try to deploy the add-on (the same project) on a https server, and install the add-on, the output is different, and there is not rendering content at all. Can someone help me on this case?
Hi @Ivana1, when you run ACE locally, I imagine you have the credentials.json
file present, which contains your instance name and API token. With that file present, ACE will invoke some magic (run ngrok tunnel, install app on your instance, etc.) When you run this app on a remote server:
- remove that credentials.json file
- update your
config.json
AND/OR descriptor (atlassian-connect.json
) to make sure your descriptorâsbaseUrl
correctly reflects the hostname of where your http server is running. - your host needs to be behind
https
If youâve already covered the above, and are still having problems, please post any output (errors or logs). Please be sure not to include any sensitive information (i.e. access tokens, etc.)
Thanks,
Neil
Thank you @nmansilla for the response. Yes, I follow the steps, remove the credientials.json file, made the changes in the mentioned files, but since the add-on is dynamic I use authentication type âjwtâ, and coming up with this type of error
Hi @Ivana1 ,
Have you tried viewing your appâs Connect descriptor in a browser to see how it renders? If that looks OK, you can then try sending a POST request to your appâs /installed
endpoint with dummy data to see if it returns a 404. My guess is a configuration problem.
Regards,
Dugald
Hey there,
Check if your atlassian-connector.json âlifecycleâ section has âinstalledâ key value set. This is the endpoint where Atlassian will send POST request to confirm add-on install. E.g.
"lifecycle": {
"installed": "/installed"
}
This endpoint needs to respond with 204 or 201 HTTP code. If youâre using latest ACE version - this endpoint route is automatically set up when addon is being bootstrapped (as in you donât need to write code for this route, unless you want to do something custom when request is sent).
Next try using some HTTP client (Postman, Boomerang, etc) to send POST to this endpoint to see what your server responds with. Use {{localBaseUrl}}
value for host and /installed
for path, e.g. if {{localBaseUrl}}
is set to https://my-app.com
, then you should send POST to https://my-app.com/installed
and review result. At the same time you could run Node.js server in DEBUG mode to see requests/responses to your server in real-time.
Thatâs the start. Once youâve done above and didnât find the issue - report back.
Hi @ViliusZigmantas. I am having a similar issue with my install process. This reply of yours helped me to confirm that my /installed route is working. The reply I got is: âInstallation verification error: 401 No baseUrl provided in registration info.â
I could use some help putting together the data for the POST /installed call from Postman to get closer to the source of my issue. I have not found any description of that call
If you or any other could have a look at it and reply to me in my thread: Cannot install ACE React app from Heroku
All help very much appreciated
The /installed
endpoint, and all the lifecycle events are documented with the Connect app descriptor. Specifically, you can find an example request payload.
That said, I would agree with @nmansilla about where the most common problems exist: in the baseUrl
for the app, and in making sure the app is available on valid HTTPS. One thing that I do for debugging is to make sure to log lifecycle events and trap errors (example in Node.JS Express, not ACE. Some adjustments will be necessary).
@ibuchanan thanks for pitching in and sharing the trap script (nice!)
@HallbjrnMagnsson during initial dev I have found Atlassian Connect Inspector tool useful. It creates atlassian-connect.json which will be valid for 3 days that you can install on your Jira instance and try out various lifecycle events in real-time and see all the payloads.
If you have proper dev env set up, you should be able to see all incoming requests and payloads through Ngrokâs web-app too.
Hi @ViliusZigmantas
I have developed an ACE cloud add-on with Node.js.
The add-on works properly on a local machine, with npm start and development as an environment. We put the same add-on on a Linux server, and try to start it from our own https server (without ngrok). The configuration is the same as the local machine.
Use case 1: We run the pm2 start npm â start command, the descriptor is served from the https url from the browser, and we successed to install it on the cloud instance (without errors on server), but the add-on is not working, thus is not rendering the content from the endpoints. This is the first use case where we use authentication type set as none.
Use case 2: When we use authentication type: âjwtâ and with lifecycle âinstalledâ., we came along with the error :
And in the Postman when we try yo send POST to this endpoint ("/installed"), the server response with 404 error.
Does someone has an idea why the addon doesnât work properly from the server? Is it the wrong command for starting, problem with the authentication types, or maybe the configuration file. (just to note that we want to test the addon on the https server but in the development environment).
Thank you
HTTP 404 status in the error message indicates that your server doesnât answer to your Jira Cloud instance when it tries to confirm installation by attempting to load https://<baseUrl>/installed
- Navigate to your
atlassian-connect.json
URL and check what value is set forbaseUrl
- Confirm that your HTTPS certificates are valid and not expired
- Check the web-server logs to confirm that there are attempts logged to access
atlassian-connect.json
and/installed
(and check for any errors)
Additional things you could try:
- check your appâs
config.json
and confirm if it hasproduction
section, then check the values set inlocalBaseUrl
andport
(this is the URL:PORT that your app is running on, where web-server would usually proxy requests to it) - as suggested earlier try to use some HTTP client to send POST to
https://<baseUrl>/installed
(see sample POST payload below) -
/installed
endpoint is expected to respond with 201 or 204 HTTP status, check if you have a custom route in your code for/installed
endpoint (usually there is no need to define custom one, since ACE will define one during bootstrapping, I have found it better than my custom one)
Sample POST payload for /installed
:
{
"key": "<application-key-from-ace-descriptor>",
"clientKey": "<unique-id-for-your-cloud-instance>",
"publicKey": "<public-key-for-auth>",
"sharedSecret": "<shared-secret-for-auth>",
"serverVersion": "100166",
"pluginsVersion": "1001.0.0-SNAPSHOT",
"baseUrl": "<your-cloud-instance-url>",
"productType": "<product-value-from-config-json-or-default>",
"description": "Atlassian JIRA at <your-cloud-instance-url> ",
"eventType": "installed"
}
Could you please provide more details on how youâre starting the application on the server?
- Is it manually launching
npm start
or throughsystemd
service ornodemon app.js
or in some other way? - Can you confirm that
NODE_ENV
is actually set toproduction
? You could set it explicitly withNODE_ENV=production node <main-script>.js
- where
<main-script>.js
is your entry script which loads express.js, bootstraps ACE, defines routes and starts HTTP server to listen for connections - command expects
node
to be in your$PATH
, if it is not then instead ofnode
type in full path to the binary (e.g.NODE_ENV=production /usr/local/bin/node <main-script>.js
- where
- Can you start your app with DEBUG enabled and check if all endpoints are set up during launch (or catch any other errors)? Use
DEBUG=express:* node <main-script>.js
Hope that something from above will help. Good luck and patience.
Thank you @ViliusZigmantas
Everything is done and it works now.
@Ivana1 any chance you could share which suggestion have worked for you to solve the issue?
Yes of course.
Firstly I noticed that the nginx server configuration was not correct. The nginx was not serving the static files, just the descriptor, so I changed the location in the server block. Then I had a custom route in my code for â/installedâ endpoint, which I delete it afterwards, and this solved my HTTP 404 error. Also I added the localBaseUrl in the config.json file in the development environment to be my https server url . (just to note that the whole testing was in development environment).