January 16

Hi everyone! Hope you're doing well, it's cold as heck here >_< 

Stripe integration

I’ve started integrating Stripe payments into the website. The basic proof of concept is done, so most of the work should be quite straightforward from here, though there's a fair bit of it to do.

Mainly it comes down to testing all the different error and payment scenarios, implementing the webhook and confirmation pages to handle those, and refining the checkout page.

Security improvements

As part of starting to implement Stripe integration, I ended up going down the rabbit hole of security again - one can never be too careful. While SameSite attributes on cookies prevents the vast majority of CSRF attacks now, alongside cookie_secure and http_only settings, I decided that wasn’t enough for my liking. I’ve therefore implemented anti-CSRF tokens and headers for additional security layers.

For pages that can invoke state changes, like say the submit artwork page, an anti-CSRF nonce is now generated and sent to the client as a meta tag, which is then returned to the server as a custom request header. An additional anti-CSRF custom request header is also sent with all requests now, as a further precaution, though it is only tested in sensitive forms and other sensitive areas (to prevent ordinary links to the site breaking).

ID storage improvements

Storing unique IDs efficiently in MariaDB turned out to be a slight nuisance. For database purposes, it makes more sense to store unique IDs as BINARY(16) columns instead of VARCHAR(36), as it’s more efficient on space. However, only the very newest versions of MariaDB have built-in functions to convert between the two formats… thankfully someone has already had this problem and wrote functions for doing the conversion, so I mostly had to make a bunch of code and stored procedure changes to make that work.

Navbar and included files cleanup

Maintaining pages that have a lot of dynamic elements like the navbar was probably going to be tricky in future, at least in the current design. Having a whole bunch of PHP code within the file echoing things makes it awkward to maintain, so I’ve now split up all such files into a bunch of files that can be included when conditions are met, making it much easier to maintain and separating the code out more.

Twitter authentication

While I’d ideally like to make a useful retweet tool for the site (rather than the useless, standard “post a tweet from our site with a crappy embedded link” solution), right now I don’t have the time for that yet.

However, making a simple app to interact with the Twitter API and prove a user owns a particular account is fairly easy now, as I’ve already gotten to grips with the more complex authentication system of their new API for ArtRetweeter’s development. I’m going to use this to make it easier for artists to have their work taken down from Deserted Chateau if e.g. a user is stealing their work; authenticating their Twitter account makes it easy to prove the takedown is coming from the genuine source of the artwork, without someone having to make an account on my site and so forth.

Twitter’s current chaos is unfortunately spreading in the dev department, and right now it’s unclear if I will be able to get the permissions to actually make this without deleting one of my existing apps, as most developers are limited to three apps right now, all of which have shared read and write limits. Most irritating - either way I will leave this until I have more clarity from them.

Account deactivation

This is mostly finished. I’ve implemented a footer that sits at the bottom of the page when a user has marked their account for deactivation (so they don’t forget, to avoid weird accidents, etc), and written the stored procedures for actually deleting an account. The remaining task is to make the cronjob that will actually perform the deletions and test it.

I’m also partway through implementing forgotten password functionality - i.e. sending an email with a link in it when the user has forgotten their password. I’ll finish this when the site’s logo is finished, which should be soon, I’m looking at the final revisions at the moment. It’ll be easier to do the email template designs when the logo is done so that it doesn’t need changing.

CloudFront: Signed urls for 4K image display

To control exactly who can view 4K resolution versions of images (when the artist has chosen to make them available), I’ve changed some of the image uploading and resizing code so that they are now accessible only via signed URLs. This also makes the process of handling unsubscribing users easier, as instead of having to delete all the 4K resized artworks when a user’s subscription expires and remaking them later, the servers can simply not provide the signed URL until the user resubscribes.

CloudFront: custom error pages

Normally, if a user goes to a CloudFront hosted resource and a HTTP error is returned, you get the ugly default CloudFront error page.

AWS allows custom error pages to be defined for a bunch of different status codes, so I’ve made custom error pages. I’ll need to also change the normal error pages on the website to have a similar structure, but that’ll be easy. Meanwhile, the Deserted Chateau CDN distributions now have much nicer error pages.

Cookie Consent Popup

Most websites are required to have the annoying “cookie consent popup” by EU law - basically any site using “non-essential” cookies. Deserted Chateau doesn’t use any non-essential cookies (there’s no analytics, marketing cookies etc), so the only thing I had to check was whether hCaptcha, the CAPTCHA implementation I’m using, would cause the site to need one.

hCaptcha’s privacy policy explicitly specifies that it’s not needed, so thankfully Deserted Chateau needs no cookie consent popup (which will make the site a bit nicer to use, and it means I don’t have to implement one).

Artwork display pages improvements

I’ve made some minor improvements, mostly to fix the image layouts and also the backend code that actually renders the page.