JILS-48: Allow conditional submission of comments

Issue Information

Issue Type: New Feature
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: Jira Issue Listing Script (JILS)
Resolution: Won't Fix (2019-09-09 16:34:21)
Target version: 0.01b,

Created: 2018-03-22 09:20:24
Time Spent Working
240 minutes
240 minutes
0 minutes

Currently a JILS archive is read-only, viewers cannot comment on issues without either visiting JIRA directly (or perhaps being given an email address for the mail handler).

What I'd like to implement is a conditional ability to add comments.

It needs to be conditional because, at least to begin with, I don't want it active on projects.bentasker.co.uk, but may want it active on customer specific mirrors. As they share a back-end, it therefore needs to be possible to control the availability in some way.

It also needs to be locked down so that the submission handler (which might even be shared between mirrors) cannot simply be used to spam comments in.

Toggle State Changes


One possible solution would be this:

Add a flag for the mirrors to use to disable the comment form (or, perhaps, to enable it if we want it off by default, probably best to have a config value decide what the default behaviour is)
When an issue page is generated and the form enabled, we should go through the process below to help restrict access to the mailing end point

Generate a JSON string:
"Issue": [issue key],
"destaddress" : [mail handler address],
"seqno": [integer],
"expires": [epoch timestamp]
"signature": [see below]

The signature would be generated by concatenating the other attributes and then either adding a shared secret and hashing, or signing with a public key (probably more secure, but incurs a lot of overhead).

The JSON string would then be base64 encoded and added into the comments form as a named value. The mailing endpoint would need to validate the signature, and only send the comment into JIRA if it matched.

This would do nothing to address spam originating from a legitimate page (as the token would be valid), but would at least stop messages being squirted at random into the endpoint. As the tokens have a limited life (would need to be more than the cache lifetime for any mirror using a caching reverse proxy) a spammer would need to periodically re-grab a token.

When submitting to the endpoint, the user's name and comment would need to be included, but shouldn't be included in the signature (as that would need to happen client-side, thus revealing the secret). Potentially the HTTP Referer header could also be used as a validation source (though I don't like that as not all browsers send Referer headers, and that's only going to increase now that we've got the HTTP Referer-Policy header).

As it may eventually wind up on a public facing site, we also need to try and mitigate the likelihood of bot spam. One approach would be to inject the server generated values as non-form elements and use javascript to build the form:
<div id="placeholder">
<meta id="token" content="[token]" />
<meta id="endpoint" content="[mail endpoint address]" />

<script type="text/javascript">
var f,ep,n;

f = document.createElement('form');

ep = document.getElementById('endpoint').getAttribute('content');

n = document.createElement('input');

t = document.createElement('textarea');

tokstr = document.getElementById('token').getAttribute('content');
tok = document.createElement('input');

s = document.createElement('input');


That'd at least exclude any bots which don't bother to process javascript when looking for victims (which is currently quite a proportion of them).
Bulk Change.

Clearing out old issues - it's unlikely I'll find time to do any further work on JILS.

New issues will be raised for relevant items if that proves not to be the case
btasker changed status from 'Open' to 'Closed'
btasker added 'Won't Fix' to resolution