# Comments

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.


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.