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
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.
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
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 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.
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.
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.