I just finished my alpha version of the chrome extension I call "Jicky" - quick issue creation for Jira. Here are some learnings from this project.

Background

Jira is a really awesome ticket/issue tool, especially for IT projects. Being awesome sometimes also means being complicated at certain points. So, every time you want to quickly enter an issue, it involves the following steps:

  • open your browser
  • go to your Jira site
  • click "create issue"
  • select the project and issue type
  • enter summary and description
  • save

Before you hit save you can check a box to create another issue so from that point on it goes a little bit faster. When using this option, the last selected project and issue type are already selected.

Faster with Jicky

With the Jicky chrome extension, I wanted to make this a little bit faster. We usually need this when sitting in a review, checking the tasks that we have done. Every time we find an issue, we quickly want to add it to Jira and move on.
The above steps can be reduced to the following with Jicky (and almost without using your mouse):

  • open your browser (if you're reviewing a website, this step is also not necessary, because it is already open ... if it's chrome ;) )
  • Use ⌘+J or ctrl+J as shortcut
  • enter summary and description
  • save

To achieve all of this, you need to set the URL of your Jira installation and set up a default project with a default issue type in Jickys options. Currently I assume that all the Jira projects are configured to have at least a summary and description field, although, in rare scenarios, this might not be the case.

Technical Background

Jira has an API, so using it with 3rd party software is actually pretty easy. The problems come up with the authentication against the Jira server.

Jira Login Options

Jira currently offers the following login options

  • Basic Auth
  • oAuth
  • Cookie
Basic Auth

Pro

  • easy to implement

Con

  • should only be used with secure connections
  • extension needs to store the credentials somewhere save
oAuth

Pro

  • no credentials need to be stored, just a token

Con

  • the Jira Server Admin needs to setup the application for oAuth, also meaning that the extension would probably need a server implementation at some point to handle the oAuth stuff

Pro

  • no credential handling on the extension side at all (oh yeah, let's go with this)

Con

  • none on Jiras side
Chrome Restrictions

Now the annoying part kicks in.

Cookie Header

My first idea was using the Basic Auth stuff and just storing the cookie from Jira in my extension. That worked out well ... until I wanted to send this cookie via header to my Jira site. Cookie-Header is a forbidden header, so you cannot use it.

I found out, that I don't have to send the cookie via header. Chrome sends the cookies stored for the requested site with my request. That's awesome and the way to go for now.

Unfortunately, the upcoming part SameSite Cookies will explain the next issue.

SameSite Cookies

So for now, everything works. In my extension, you just enter your Jira URL and I'll check with the given cookie if you're logged in. If so, we're good to go, but:
chrome is already giving me a warning about feature releases:

A cookie associated with a cross-site resource at http://jira.example.com/ was set without the 'SameSite' attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with 'SameSite=None' and 'Secure'.

If Jira (spoiler alert: it will not) would deliver the cookie with SameSite=None, everything would be fine. I could still use the cookie for my extension and no login method would be needed.

Since my extension should be used be everyone without the need of an Jira server admin, the last method that is left to be used is Basic Auth. At that point, I have to deal with the next chapter issue of Insecure storage.

Insecure storage

In the end, I will end up here. I need to request username and password from the user in order to call the Jira API with that user. So, how can I securely store the user's credentials?
Honestly, I don't know yet.

My current plan is to still read the Jira Site cookie, use the value to encrypt the BASE64 basic auth credentials and store them. If I'm unable to restore the credentials, the user has most likely a new session and needs to re-login with my extension. That's really inconvenient for the user, but more convenience will mean less secure and from the past I remember how unhappy users are with storing their credentials in a chrome extension.

It seems that there's another way, using the chrome.identity API. I have to take a deeper look into that, but from my first check it seems that I would need to use oAuth which wouldn't fit with my intention that everyone can use it without being a Jira admin.

unsplash-logoMarkus Spiske