# Zsolt brought up the question of security around using WordPress for private journaling considering the WP REST API relies on username & password.
You could look at JSON web tokens (JWT) but would still need to initially send your username and password to get the token.
Or maybe OAuth 2 but that could be tricky based on how you're connecting (Drafts doesn't have support for authentication via OAuth. Yet. Fingers crossed.)
I presume he asks because his blog is http rather than https.
This is why I said that my Drafts 5 action and basic authentication should never be used over http.
The way I connect passes an encoded version of my username and password as part of the query. If this was done over http it would be easy to grab and decode those details but because I use https it cannot be intercepted by a "man in the middle" style attack.
Private posts can only be retrieved by a properly authenticated user via the REST API so, I’d argue, things are safe when using https.
Comments
# Of course, one could always disable the WordPress REST API if sufficiently worried and didn't have any need for it.
Comments
# The idea of a private journal within WordPress is certainly intriguing, notwithstanding potential security caveats, so I decided to look at a more specific solution to just creating private posts.
As suggested yesterday I registered a custom post type to keep things separate from the blog. In doing so I added support for the REST API (so that I could still posts from Drafts) by adding 'show_in_rest' => true to the register_post_type() function.
This in turn creates a new API endpoint /wp-json/wp/v2/journal instead of the usual /posts so I updated the Drafts action accordingly.
Next I added an additional menu item only visible when is_user_logged_in() is true.
And that's it, that's all it needs.
Adding REST API support is obviously not required if not posting via this method so excluding show_in_rest or explicitly setting it to false cuts off this potential avenue of access.
To retain posting support I'm also looking at the possibility of redirecting just the GET method to a custom callback.
@colinwalker
That’s what concerns me. No additional security other than a username/password can be used with the REST API to retrieve private posts, and I had a blog hacked once using a security error in WordPress. There should be a stronger authentication (maybe two factor) for the REST API too. Sure, I could disable it altogether, but that’s also annoying.
I’m just not comfortable storing private stuff on WordPress I think.
Colin Walker brought up yesterday the idea of using your website as a private repository. This also occurred to me a couple of months ago when I searched a better alternative for Day One. This blog which runs on WordPress looked great for a private journal, but I didn’t find anything that would migrate my entries from Day One, so I created a script for myself. I’ve open sourced it on GitHub so anybody with a little bit a terminal knowledge should be able to use it. Before you ask: I still use Day One with encryption turned on. When I reasearched the topic of private posts using WordPress I found a couple of security concerns which I’ve also shared on Colin’s blog. But after last week’s Day One security fiasco, maybe it’s something that I should reconsider.
@colinwalker I also open source the import script for Day One to WordPress I mentioned yesterday. Maybe somebody else will need it. decoding.io/2018/05/4...
@zsbenke I’m going to do a full write-up of what I’ve been doing but one option is to register a custom post type and not include support for the Rest API.
@zsbenke ooh, this would be very helpful, thank you!
definitely have thought about it many times. Thanks for the link and the work on the script! (Ugh. Ruby!)