I've never really been one for private journaling. When I did try Day One a while back it didn't stick probably because I post to the blog so regularly.
Posting private items to WordPress is something I've considered and dismissed before; however, Jonathan's microcast made me reconsider.
As I now post everything directly from Drafts it's simple to duplicate my "Post" action and change it to set the post status as Private. This means I don't have to adopt a different workflow for anything I might want to submit as anything approximating a journal entry.
Now, I don't know whether to exclude such entries from the blog even when logged in and set up a separate, private page. I could even go one stage further and create a custom post type.
Much to consider.
@colinwalker I’ve tried a setup like this, I even created a script which fed my Day One library into WordPress with images and everything. But at the end, I just don’t trust WordPress as a secure place for those posts.
I mean I store some really personal stuff in Day One which I can encrypt at least. There is no decent two factor authentication for WordPress, since the API still secured with username and password.
@zsbenke Thanks for the thoughts Zsolt, those are definitely valid concerns. I need to work out all the logistics and may not even end up using this but it’s something worth looking into.
@colinwalker Please share what you've found. I'm still trying to move away from Day One and my own blog looks a cool tool for a private journal. I just don't know how to secure it enough.
@zsbenke Of course.
So, thanks Colin for sharing the link about the Day One issue. I didn't know they'd finished their postmortem and that there had been any kind of privacy breach at their end. My reaction to that - meh. I do put a lot of ridiculously personal data into Day One, but stuff like this happens and I don't mind forgiving them for it.
As for WordPress, I think we've talked about this before, but I'd like to reiterate - I LOVE WordPress for private posts! I've basically set it so that all new posts get created and immediately published as Private posts (if I'm using the web UI, it's automatic), and once I decide the final nature of the post (should it be public or private) I change the setting of the post.
This is a great way for me to quickly jot down some notes or thoughts and have them sitting, timed, on my blog.
Of course, I would not put on my blog what I do in Day One. That's just because the content is often very different.
Thanks Nitin. Yes, I remember you mentioning that before.
Obviously, your use of private posts is different to a Day One type implementation, you’re using it more as “draft” status. It could be done either way.
I’ve been looking at this a bit more and will post soon.
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 things are safe when using https.
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.
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.
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 theregister_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 whenis_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.