Adding an inline post editor to my blog + security concerns addressed

This is a mirrored post from https://reaper.im/blog

We've had this blog for a while now and the typical flow of writing a post is me going to Mark, writing the post markdown, exporting the file, adding the metadata to the file which involves the title,publish status, date, and then pushing the repository after checking if the above were done properly.

Though Mark exists just because I've used other tools and Typora is the only one that comes close to being lightweight and aesthetic and while I do use it while I'm on the Mac, I do write a lot of these posts from an iPad and since Mark is just a web-app it works well, as for pushing the repo and creating the file, all is done using gitpod. It's pretty easy to do but yeah, a good amount of window switching.

Adding Integrations to Mark

I like how the new UI on it looks so my second plan was to add the ability to login via github on Mark, select a repository you'd like to add the markdown too and then giving the path in the repository which would've been great and I probably will do that sometime, but I wanted a little more automation since the meta data addition would still be needed and I wouldn't want to generalise mark to have datepicker when it's just for a niche use-case. Though I do have a plan for something similar so let's hope I get enough time this weekend to start with it.

Scraping BuyMeACoffee

The first approach was something I mentioned in this post which involved scraping post data from another site who's editor I liked. While that would work we'd loose offline capabilities of the repository, which I didn't want too and adding a scheduled sync action wouldn't be optimal either.

The easiest approach

The last approach was to just use a password to log into the site, add posts from a simple text area and then push it into the repository using github's API, though there were a few security risks.

1. The password could be bruteforced.
2. The attacker could throw as many files as he wanted to my repo.
3. Obviously, he could post whatever he wanted

So, we put a little more thought into it and ended up blocking this a little bit. The site uses an OTP approach instead, so it mails to one of my random non-public emails a otp that lasts for like 45-60 seconds, this kinda gets rid of the bruteforce but then it's just 6 digits, we've got computers who can kinda get through this so the next block was to create all these posts to a subset branch and
create a PR for the main branch.

This does 2 things.

1. You cannot post directly to the deployed public version.
2. I'm notified for the PR, so I'd know if there was activity that wasn't from me.

Again, there's still things that can be done that an attacker could do but a little consideration on blocking them for a while is better than leaving an open door.

Thus, the last post you saw was just me testing the whole flow after writing it all. Still got work in terms of security that could increase the friction for an attacker but I've got other tools I need to work on so we'll get to it as soon as I get time.

Adios!