atlassian-connect-express: Node.js package for Express.js based Atlassian Add-ons
atlassian-connect-express
(ACE) is a toolkit for creating
Atlassian Connect based Add-ons with
Node.js. Atlassian Connect is a distributed component model for creating add-ons.
Add-ons built with Atlassian Connect extend Atlassian cloud-based applications over standard web protocols and APIs.
To build add-ons for Atlassian's server (on-premises) products, refer to the server developer documentation.
ACE is the officially supported Node.js framework for Atlassian Connect. Please read our documentation to see the other
supported and community provided
Frameworks and Tools.
You will find the recommended tools extremely useful when writing your own Atlassian Connect add-ons; be sure to peruse
the list of tools and use them as much as possible to aid development.
Please ensure you always use the latest patch version of ACE to ensure your add-on has the latest security patches and
fixes. Versions prior to 1.0.14 and 2.0.2 have a known security vulnerability.
More info
ACE helps you get started developing add-ons quickly, using Node.js and Express as the add-on server.
It's important to understand that Express by itself is a web app framework for Node. ACE just provides
a library of middleware and convenience helpers that make it easier to build Atlassian add-ons. Specifically, ACE adds:
- An optimized dev loop by handling registration and deregistration on the target Atlassian application for you at startup and shutdown.
- A filesystem watcher that detects changes to
atlassian-connect.json
. When changes are detected, the add-on is re-registered with the host(s). - Automatic JWT authentication of inbound requests as well as JWT signing for outbound requests back to the host.
- Automatic persistence of host details (i.e., client key, host public key, host base url etc.).
- ngrok tunnel, for testing with Jira or Confluence hosts.
Release notes
For detailed release notes and upgrade guides, please see the Release Notes.
Getting started
The fastest way to get started is to install the atlas-connect
CLI tool. The CLI makes it possible to generate an ACE
enabled add-on scaffold very quickly. To install:
npm i -g atlas-connect
Create a project
Let's start by creating an add-on project:
atlas-connect new <project_name>
This creates a new project in the current directory.
Install dependencies
Change to the new project directory and install dependencies:
npm install
If you get any errors related to node-gyp (especially with Node 8 on Windows), try
installing its prerequisites.
Setting up a development environment
At this point, you're all set to run your add-on, but you still need to install it in Jira or Confluence.
You can install your new add-on in any Jira or Confluence host where you are an administrator, but usually
it's best to create a new host for you to use during development.
Follow this link to sign up
for a free Jira or Confluence Cloud host.
Running your add-on server
In your project directory, run:
npm start
This will boot up your Express server on the default port of 3000.
Dev loop
At this point, you can start building your add-on. Changes to views load automatically, however, if you make changes to
any JavaScript, you need to restart Express. If you want your server to automatically restart when your JavaScript
changes, consider using nodemon or the like.
Automatic registration
This section will describe how to configure ACE so that it can automatically register your add-on with your
Jira or Confluence host, re-register on changes to the descriptor, and de-register on shut down.
To get this functionality, you will need to:
- Install ngrok:
npm install --save-dev ngrok
, - Create a file called
credentials.json
, - Copy and paste the contents of this file,
- Add
credentials.json
to the .gitignore
file, and - Change the contents of the file to contain the link to your development environment, e-mail as the username, API token as password and product name.
ACE will now read this file and automatically create an ngrok tunnel, and register your add-on on your development host.
Configuration
The configuration for your add-on is done in two files:
./config.json
-- This file contains the configuration for each runtime environment your plugin runs in. The file has
comments to help you understand available settings../atlassian-connect.json
-- This file is a manifest of all the extension points your add-on uses. To see all of the available extension point options for Jira, check out the modules sections of the
atlassian-connect Jira modules documentation. To check out all the available extension point options for Confluence, check out the modules section of the
atlassian-connect Confluence modules documentation.
The behaviour of your add-on can be further configured by setting the AC_OPTS
environment variable (see the end of this section).
config.json
The ./config.json
file contains all of the settings for the add-on server. This file is broken into environments.
{
"expressErrorHandling": false,
"signed-install": "force",
"development": {
"port": 3000,
"validateDescriptor": true,
},
"production": {
"port": "$PORT",
"localBaseUrl": "https://your-subdomain.herokuapp.com",
"store": {
"dialect": "postgres",
"url": "$DATABASE_URL"
},
"allowedBaseUrls" : [
"https://other-domain.herokuapp.com"
],
"whitelist": [
"*.jira-dev.com",
"*.atlassian.net",
"*.jira.com"
]
}
}
AC_OPTS
The AC_OPTS environment variable can be used to change the behaviour of ACE for ease of development, like so:
AC_OPTS=no-auth,force-reg node app.js
Set it to a space or comma delimited list containing one or more of the following values.
force-reg Make the add-on always register itself with running a Jira or Confluence host when it starts up
(normally auto-registration only happens if the add-on is using a memory store).
force-dereg Make the add-on always de-register itself with running a Jira or Confluence host on shutdown
(normally auto-registration only happens if the add-on is using a memory store or running in development mode).
no-reg Make the add-on never register itself with running a Jira or Confluence host
(i.e. don't auto-register even if a memory store is being used).
no-auth Skip authentication of incoming requests (i.e. don't check for or validate JWT tokens).
atlassian-connect.json
The atlassian-connect.json
describes what your add-on will do. There are three main parts to the descriptor: meta
information that describes your add-on (i.e., name, description, key, etc.), permissions and authentication information,
and a list of the components your add-on will extend. This descriptor is sent to the host (i.e., Jira or Confluence)
when your add-on is installed.
To see all of the available settings in the atlassian-connect.json
, visit the module sections of the
atlassian-connect documentation
If you need a pre-processing step to your descriptor, you can configure one by changing your app.js
so that a transformer is included in the config
. The descriptorTransformer
property expects to be a
function and passes in descriptor
as an object, and the app.config
object.
var addon = ac(app, { config: {
descriptorTransformer: function(descriptor, config) {
if (config.environment() === "production") {
descriptor.key = "production-key";
}
return descriptor;
}
}});
Sample Add-ons
Scaffold
When you generate a new ACE add-on, you're actually just downloading a copy of the
Atlassian Connect for Express.js template.
Handlebars layouts and templates
The base scaffold uses the Handlebars template library via the express-hbs package.
Handlebars views are stored in the ./views
directory. The base template contains a layout.hbs
and a sample page
(hello-world.hbs
). Handlebars alone doesn't provide layouts, but the express-hbs
package does. To apply the
layout.hbs
layout to your template page, just add the following to the top of your template:
{{!< layout}}
To learn more about how Handlebars works in express.js, take a look at the express-hbs documentation.
Special context variables
ACE injects a handful of useful context variables into your render context. You can access any
of these within your templates:
title
: the add-on's name (derived from atlassian-connect.json
)addonKey
: the add-on key defined in atlassian-connect.json
localBaseUrl
: the base URI of the add-onhostBaseUrl
: the base URI of the target application (includes the context path if available)hostStylesheetUrl
: the URL to the base CSS file for Connect add-ons. This stylesheet is a bare minimum set of styles
to help you get started. It's not a full AUI stylesheet.hostScriptUrl
: the URL to the Connect JS client. This JS file contains the code that will establish the seamless
iframe bridge between the add-on and its parent. It also contains a handful of methods and objects for accessing data
through the parent (look for the AP
JS object).token
: the token that can be used to authenticate calls from the iframe back to the add-on service.license
: the license statuscontext
: the JWT context
claimclientKey
: the client consumer key used to identity the Jira or Confluence host from which the request cameuserAccountId
: the Atlassian Account ID of the user.userId
: (deprecated) the username of the user from which the request came.timeZone
: (deprecated) the user's timezonelocale
: (deprecated) the user's locale
You can access any of the variables above as normal Handlebars variables. For example, to generate a link in your page
that links elsewhere in the host:
<a href="{{hostBaseUrl}}/browse/JRA">Jira</a>
Events emitted
All products
host_settings_saved
: after /installed
lifecycle, ACE tries to save the client information (baseUrl, clientKey, app key, puglinsVersion, productType, publicKey, serverVersion, sharedSecret) in storage. If successfuly saved, this event is emittedhost_settings_not_saved
: after /installed
lifecycle, ACE tries to save the client information in storage. If there's any error or problem, this event is emittedaddon_registered
: after an ngrok tunnel is created, ACE will try to register or install the app in a Jira or Confluence productwebhook_auth_verification_triggered
: ACE automatically registers webhooks and corresponding paths in the descriptor file, once it tries to authenticate this event is emittedwebhook_auth_verification_successful
: ACE automatically registers webhooks and corresponding paths in the descriptor file, once it tries to authenticate and is successful, this event is emitted
Jira/Confluence
localtunnel_started
: event emitted after ACE successfully creates an ngrok tunneladdon_deregistered
: when ACE receives a SIGTERM
, SIGINT
, and SIGUSR2
signals, it will deregister the app and this event is emitted
To listen to an event:
addon.on(event, function() {
// Add something here
});
Recipes
How to secure a route with JWT
Add-ons are authenticated through JWT. To simplify JWT verification on your routes, you can simply add an
ACE middleware to your route:
module.exports = function(app, addon) {
app.get(
'/protected-resource',
addon.authenticate(),
function(req, res) {
res.render('protected');
}
);
};
Simply adding the addon.authenticate()
middleware will protect your resource.
Authorizing requests
If your app API accepts requests from the front-end using context JWTs, it's important to perform authorization checks.
Atlassian Connect Express includes a basic middleware that leverages the Jira get bulk permissions API and Confluence check content permissions API to perform authorization checks based on the context JWT.
For example to restrict an endpoint to Jira admins that are also project admins:
module.exports = function(app, addon) {
app.get(
'/admin-resource',
[
addon.authenticate(true ),
addon.authorizeJira({ global: ["ADMINISTER"], project: ["ADMINISTER_PROJECTS"] })
],
function(req, res) {
res.render('protected');
}
);
};
Similarly for Confluence, to restrict an endpoint to Confluence admins that also have permissions to read the current page:
module.exports = function(app, addon) {
app.get(
'/admin-resource',
[
addon.authenticate(true ),
addon.authorizeConfluence({ application: ["administer"], content: "read" })
],
function(req, res) {
res.render('protected');
}
);
};
How to send a signed HTTP request from the iframe back to the add-on service
The initial call to load the iframe content is secured by JWT, as described above. However, the loaded content cannot
sign subsequent requests. A typical example is content that makes AJAX calls back to the add-on. Cookie sessions cannot
be used, as many browsers block third-party cookies by default. ACE provides middleware that
works without cookies and helps making secure requests from the iframe.
Standard JWT tokens are used to authenticate requests from the iframe back to the add-on service. A route can be secured
using the addon.checkValidToken()
middleware:
module.exports = function(app, addon) {
app.get(
'/protected-resource',
addon.checkValidToken(),
function(req, res) {
res.render('protected');
}
);
};
In order to secure your route, the token must be part of the HTTP request back to the add-on service. This can be done
by using the standard jwt
query parameter:
<a href="/protected-resource?jwt={{token}}">See more</a>
The second option is to use the Authorization HTTP header, e.g. for AJAX requests:
beforeSend: function(request) {
request.setRequestHeader("Authorization", "JWT {{token}}");
}
You can embed the token anywhere in your iframe content using the token
content variable. For example, you can embed
it in a meta tag, from where it can later be read by a script:
<meta name="token" content="{{token}}">
How to send a signed outbound HTTP request back to the host
ACE bundles and extends the request HTTP client. To make a
JWT signed request back to the host, all you have to do is use request
the way it was designed, but use a URL back to
the host's REST APIs.
var httpClient = addon.httpClient(req);
httpClient.get('/', function(err, res, body) {
...
});
If not in a request context, you can perform the equivalent operation as follows:
var httpClient = addon.httpClient({
clientKey: clientKey
});
httpClient.get('/', function(err, res, body) {
...
});
By default, these requests are authenticated as the add-on. If you would like to make a request as a specific user, the
#asUserByAccountId()
method should be used. Under the covers, an OAuth2 bearer token will be retrieved for the user
you've requested.
var httpClient = addon.httpClient(req);
httpClient.asUserByAccountId('ebcab857-c769-4fbd-8ad6-469510a43b87').get('/rest/api/latest/myself', function(err, res, body) {
...
});
Ensure you pass the userAccountId
value into the method, and not the username or userKey. If you were previously using
#asUser()
with userKey
, you can convert it into a userAccountId through the User REST resource on the host product.
You can also set custom headers or send a form data. Take, for example this request which attaches a file to a Jira issue:
var filePath = path.join(__dirname, 'some.png');
fs.readFile(filePath, function(err, data) {
httpClient.post({
url: '/rest/api/2/issue/' + issueKey + '/attachments',
headers: {
'X-Atlassian-Token': 'nocheck'
},
multipartFormData: {
file: [data, { filename: 'some.png' }]
}
},
function(err, httpResponse, body) {
if (err) {
return console.error('Upload failed:', err);
}
console.log('Upload successful:', body);
});
});
Using the product REST API
Certain REST URLs may require additional scopes
that should be added to your atlassian-connect.json
file.
How to deploy to Heroku
Before you start, install Git and the Heroku Toolbelt.
If you aren't using git to track your add-on, now is a good time to do so as it is required for Heroku. Ensure you are
in your project home directory and run the following commands:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
ssh-keygen -t rsa
git init
git add .
git commit . -m "some message"
heroku keys:add
Next, create the app on Heroku:
heroku apps:create <add-on-name>
Next, let's store our registration information in a Postgres database. In development, you were likely using the memory
store. In production, you'll want to use a real database.
heroku addons:add heroku-postgresql:hobby-dev --app <add-on-name>
Lastly, let's add the project files to Heroku and deploy!
If you aren't already there, switch to your project home directory. From there, run these commands:
git remote add heroku git@heroku.com:<add-on-name>.git
git push heroku master
It will take a minute or two for Heroku to spin up your add-on. When it's done, you'll be given the URL where your
add-on is deployed, however, you'll still need to register it on your Jira or Confluence host.
In order to run your add-on on a Jira or Confluence host, you must enter production mode. To achieve this,
set the NODE_ENV
variable to production like so:
heroku config:set NODE_ENV=production
For further detail, we recommend reading
Getting Started with Node.js on Heroku.
Troubleshooting
"Unable to connect and retrieve descriptor from http://localhost:3000/atlassian-connect.json, message is: java.net.ConnectException: Connection refused"
You'll get this error if Jira or Confluence can't access http://localhost:3000/atlassian-connect.json
.
One way to debug this is to see what the command hostname
returns.
If it returns localhost
, change it. On a OS X, you'll need to set a proper "Computer Name" in System Preferences > Sharing.
Debugging HTTP Traffic
Several tools exist to help snoop the HTTP traffic between your add-on and the host server:
- Enable node-request's HTTP logging by starting your app with
NODE_DEBUG=request node app
- Check out the HTTP-debugging proxies Charles and Fiddler
- Try local TCP sniffing with justniffer by running something like
justniffer -i eth0 -r
, substituting the correct interface value
Getting help
If you need help using Express.js, see the API reference or developer's guide.
If you need help developing against Atlassian products, see the Atlassian Developer site.
If you need help using functionality provided by ACE, or would like to report a problem with the toolkit, please post in the
Atlassian Developer Community.
Contributing
Pull requests, issues, and comments are welcome! It's also open source Apache 2.0. So, please feel free to fork and send us pull requests.
For pull requests:
- Add tests for new features and bug fixes.
- Follow the existing style.
- Separate unrelated changes into multiple pull requests.
See the existing issues for things to start contributing.
For bigger changes, make sure you start a discussion first by creating an issue and explaining the intended change.
Pull Requests
We take the 'trust' approach when it comes to pull requests. This means that reviewers should feel comfortable approving a PR with outstanding items due to trust in knowing that the PR owner will address the actions as necessary. Use actions for PR items that are particularly important since these require the PR owner to explicitly acknowledge them before merging
Unit tests
Run npm run test
.