- Seamless posts addition

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

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

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

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.