Hi,
Could it be possible to move the usage of the token from the query parameter to a HEADER like X_JOPLIN_TOKEN or something like that, which could be little be more secure and avoiding to be exposed by intermediaries ?
1 Like
I mentioned this a year ago. Unfortunately nothing came of my suggestion.
I can't really recall what the reasoning was (for not allowing me to move the token to the header).
1 Like
if the anwser will be no, we will forget that.
thanks @tessus
I think it was because I mentioned that when I usually write an API that I allow all options: HEADER, POST, and GET for all parameters, and allow people to set precedence. Maybe Laurent thought I wanted to do the same in Joplin.
I am not saying that the answer will be no. It is also very much possible that Laurent changed his mind or that he was never opposed to using a HEADER for the token. I'm just saying that the discussion back then never had a real conclusion.
1 Like
I know, I post that here because the issue I opened for that topic is getting closed again and I open it again and so on 
1 Like
I don't see any clear reason why we should support this other than personal preferences. For example, it won't allow implementing new types of apps or new features, so based on this I'd rather not add support for header token.
I believe the original reason for it was because the query URL ends up in log, but so could the header parameters. In any case, logging must be done in a secure way.
I don't see any clear reason why we should support this other than personal preferences.
I think maybe security might be a valid and pretty clear reason? Secrets of any sort should never land in log files, period, full stop… Joplin is a fantastic note app, but it completely ignores in many ways the fact that multi-user (desktop, networked, and workstation) systems do still exist and are still in use, and attention to security details are therefore important for apps to be used/usable in certain situations. This particular issue is one of the more glaring (and easy to fix) security foibles and it's kinda silly that the idea of fixing it would be fought against in any way.
I think you are confusing things. This is the clipper API we're talking about and it's running on the user's computer only, so if they are logging all requests for some strange reason then the log is secure anyway. Or if it's not, then it doesn't matter how the token is passed.
Foxmask was using the API in an unconventional way (as an online remote server) and in that case you also need to take unconventional measures to secure your log, etc. because the app wasn't designed to be used that way.
Nope. Not confused at all. Actually found this discussion thread while searching the GitHub issue tracker for this specific issue when I found the clipper API token in the logfile. Well aware what the clipper API is and what it's used for. Was actually thinking about using the API myself from some Python code to do some potentially useful things on a multi-user system (many people can log into the same desktop machine, locally or remotely using their own separate accounts). The system is well secured as are the logfiles, and no user but the admin is able to access any files they don't already have proper permissions for. However, as a (for many years now) network administrator (both professionally and personal LAN), programmer (many languages and systems), and web developer, I happen to know a little bit about security, and secrets (access tokens, passwords, etc) landing in logfiles is bad security mojo, and makes certain software (or features of that software) unusable in certain situations. Sometimes even makes it impossible to allow the app at all, due to the potential for issues to arise. What is secure today can be compromised tomorrow, and a logfile containing secrets of any sort is gold for a malicious party to get ahold of.
There's really no valid reason to be passing an API token in a request URL these days anyhow, as passing it in an HTTP(s) header is just as easy, and avoids the logging issue entirely, as well as allows logging of cleaner and easier to read request URLs in said logfiles anyhow. There's literally no downside to switching to the more commonly used method of passing the security token in the request header, rather than as part of the request URL. Only benefits arise from the change. It's also a super-easy way to instantly silence the apparently last two of us alive on planet Earth who still care about computer/network security details. (Sorry, that probably sounded kinda snitty. I just read in the tech/security news literally every day lately about some ridiculous new data breach or ransomware attack, and I'm kinda spazzy about easily avoided security issues these days.)
Ideally (again for security purposes) the API should also have the option (or even better, the requirement) to serve over HTTPS rather than HTTP (tho I can totally understand that adds extra complexity of various sorts). Anyhow, I've rambled on long enough about this, and probably been wasting my time (and yours) anyhow, so I'll just end with this TL;DR… Main point: This otherwise fantastic note app (and don't misunderstand any of this to mean that I dislike this app; I don't; It's actually almost perfect) is sadly useless (or at least being artificially limited) to some folk due to a couple few really easy to resolve security related issues.
1 Like
I think many parts of the software could be considered unsecure if you use them in a certain context. Seems a bit crazy to me to log requests coming from the web clipper server but ok it can happen, although you have to hope that whatever is logging these requests is also not logging the headers otherwise you're back to square one.
So I see your point, but I don't feel it's a critical issue and it would be quite a bit of work to switch to headers auth as the doc and so on would also have to be updated too. Maybe as the data API becomes more frequently used there will be a stronger case to reconsider this.
Aighty. That answers it for me then. Much as I truly feel that Joplin was a nearly perfect note application for my needs, my only option at this point then is to go back to coding my own personal note application that I was working on in Python/PyQt before I found Joplin. Thanks for Joplin anyhow tho. Good app with some really great features. Keep up the good work, and have fun doin' it. That's what it's really all about after all's said and done.