cold90.com
or the year I did not release a new website framework in
Introduction
Around March 2015 I once more began thinking about settling my digital life on a domain solely owned, hosted, and administered by myself. I started my career as what would now be called a DevOps guy, so I had a pretty educated guess about what was involved.
I defined the initial requirements for my “new place” as:
- The domain name should be somewhat related to my last name
- Mail and calendar to be managed via Microsoft Exchange
- All page content served via an ASP.NET stack
I wanted a “big guys” machine, because I had decided that “this script stuff ain’t no business of mine” at the beginning of the same year. I guess this was a somewhat backwards functioning rebellion. All contact with what was then simply called JavaScript 1 was at work, hacking away at a horribly disfigured bootstrap on top of angularJs. But we also had RazorView and that seemed to me like how PHP should have been in the first place.
But Life had different plans than a new web presence in that year in store. First came a new Girlfriend, then a new Car, a new Job, and finally a new Flat. Which meant, I had to put my plans on ice and the domain slumbered.
I ATE’NT DED.
Finally, at the beginning of 2017 I fetched a new Plan. Great Things were about to happen as soon as my mobile phone contract would run out. One thing to know about me is that when I dislike a Thing I still prefer first-hand knowledge and experience with the “why I don’t like it” and after my last girlfriend dumped me (which forced me back to live with my parents) I did what every sensible mid-20 2 man would do:
I had originally planned to get the, then just released, iPhone 6 but it was basically unobtainable at that time and I had to settle for the older 3 model. And let me tell you something: I despised it. Vendor lock in is nothing you want to have but I digress.
Back when Android started to get some traction I got myself the brand spanking new HTC Desire (I miss that Trackpoint) which was then followed with a HTC 7 Trophy and finally with a HTC Windows Phone 8X. Compared to the iPhone even the HTC Desire was a Rocket and those are like a half millennia apart (in gadget years speaking). But I digressTM ..again.
Out with Exchange, In with Google Apps G Suite
On the road back to Android I decided that nothing had ever worked as good as the now dead Windows Mobile with Microsoft Exchange. But there was something similar available from Google. Albeit there’s some truth to “don’t feed the Kraken”, I decided to better drown my signals in the stream than being a wet spot on the kitchen floor 4 .
- After much deliberation I choose a nice new domain (more on that later)
- Mail and calendar completely managed via
Google AppsG Suite - All page content served via managed WordPress installation
<insert “screeching sound of stylus ripped from LP here" 5 >
Where’s that last bit coming from?
What? The thing about managed WordPress
you mean? In my endless wisdom I had made the
decision
(I.e. assumption) that the reason for me never putting something on my website was
that I spent too much time writing yet another content management system to use.
I was young but I needed the money
German proverb
I’m not proud of it but I liked WordPress. For the first 8 hours. Then I found out that the real WordPress service (where it isn’t selfhosted) Is pretty rubbish and expensive and it was ever so limiting in what you could do. I decided that getting pampered by SaaS wasn’t my thing and at last settled on a managed 6 VPS on DigitalOcean. But something was still wrong - It certainly felt better but it was still WordPress. But I wasn’t able to put my finger on what was wrong back then.
Painful, Horrific, Perplexing (PHP)
While I made the transition to DigitalOcean (and to WordPress) I had to organise a PnP Game, which required a bunch of translations to be made. This created a Problem: How to share work based on copyrighted material, safely on the internet? I’m a really law-abiding citizen by heart and I would hate to get angry letters from a publisher but what were my options?
At first I tried to solve this by using the Discussion Feature on Roll20, but their WYSIWYG editor is rubbish (How it’s possible to ☠️💫⚡🗡️⁉️! that up?). There was but one way to go: I started migrating everything to my shiny new WordPress Installation!
But now I had a problem.
On Roll20, I could easily control access to everything I translated.
Hiding stuff from people is easy but giving People which I knew had the Source Books access turned out to be the issue?
I needed additional protection for those pages referencing copyrighted stuff.
To keep it simple, I formulated these requirements:
- Access is granted via password only (Passphrase is probably a more suitable word for the context)
- There is always a main page that will handle the actual unlocking (easier to route)
- Child Pages are not visible without authentication
Every simple normal user would have just started throwing WordPress users around or used the built-in password protection feature but that would have meant removing some requirements.
Without plugins, a WordPress page can lock pages away behind passphrases but those passwords are unique to each page and don’t propagate to child pages. That meant that if I missed a child page, it would be accessible without a password, even if the main page wasn’t.
What broke the camels back was that this password had to be set on each and every page and there was no way to retrieve them again.
Some technical issues were also apparent, those passphrases were stored as cleartext in cookies (they just check for the cookies existence and send the password instead of showing the form).
I’m not sure why they thought that was a bright idea when implementing this feature.
After a while I found a plugin to take care of child pages but there was still the OpSec Issue.
Being a programmer I told myself (after the horror had abated): “I just write a plugin”. Oh Boy, I was not just going in the deep end - I climbed the jump tower and decided that the grey sludge on the bottom of the diving pool was liquid enough.
The plan I hatched was to write a WordPress plugin which would rely on the native password system but removed all child pages from the menu if it wasn’t provided by either input or cookie. Sadly, after a evening lost struggling with PHP, I found out that the plugin had no way of knowing if the current session was logged in. I had found out why they used a cookie and resend the password on each request.
On that evening I decided that enough was enough. I tried to avoid it as hard as humanly possible but there was no way around it. I needed my own CMS.
But that’s a different story. 7