Wow. Really cool. I wasn't expecting something so polished.
JIRA speed drives me crazy sometimes, so a couple of months ago I decided to build myself a tool to do instant searches/filters on multiple projects right from the browser just to scratch my own itch.
I just wanted to see if I could have near-instant filtering. I think I got a pretty decent performance by using some JS tricks. I'm sure there might be ways to make it even faster.
Page is around 70kb (HTML+CSS+JS). Everything is manually crafted. I know the design won't win a beauty contest, but it does feel instant and works for my personal use-case. I had a lot of fun building this side-project.
There is a public URL, feel free to try it out [1]. Already mentioned in a previous comment in HN a while ago [2].
[1] https://jetboard.pausanchez.com [2] https://news.ycombinator.com/item?id=44740472
For the record, it uses a proxy because of CORS. Proxy is in few lines of golang. No NPM or any other framework used to make the project. In any case, if anybody is interested in the source code to run it yourself I'm happy to make the project public. Trusting a proxy on some random's guy on internet is probably a bad idea, given all NPM shit that happened yesterday, in any case, if you want to try, feel free, but use at your own risk :P
Related: https://isanybodyusingthisprivatekey.com/
Haha, cool site
Looks cool, but definitely a security team's nightmare. Putting an API key into some random HN'ers hobby project is a bad, bad idea, whoever you are (not saying you're a bad actor, but a zero-trust policy would agree with me).
Indeed. That's why I was transparent from the start. As I mentioned, using an API key this way is generally a bad idea. Even if I'm not a bad actor (which I'm not, but you shouldn't trust me), if someone compromises my server and forges requests, they could potentially access your projects.
JIRA's OAuth implementation requires apps to be registered, involves public/private key pairs, and changes the auth flow. That adds complexity and makes setup harder, which is why I opted for a simpler API key setup, you get the API key, you write it down, you can make requests. It is just simpler and does not require JIRA admin rights.
For comparison, JiraTUI also uses the user's API token. The difference, I guess, is that it runs locally on your machine, but they could also send it somewhere else. At the end of the day, it comes down to whether you trust what you're downloading versus trusting what runs on a remote server. It is true that locally you could potentially inspect all HTTPS or even TCP requests whereas in the remote server you don't have a clue.
The thing is, OAuth in JIRA demands app registration and certificate management, so I guess many developers end up defaulting to user API keys as the path of least resistance, even if they encourage OAuth as well.
BTW, just to make it clear, in the case of jiratui you can also download from github repo directly and inspect the code if you wish :D
> they could also send it somewhere
Run JiraTui in a container / bubblewrap, and only allow it to connect to the Jira API host:port.
Wouldn’t that mean they could still exfiltrate it to another jira site they control?
Yeah, oauth would be better.