Skip to main content

March 30

Hi everyone! Hope you’re doing alright 🙂

Sorry for being late with the bi-weekly update again. ADHD medicine is… weird; while I’ve been getting a decent amount done on Deserted Chateau’s development, I’ve been struggling to get other stuff done like writing up these updates. Will take a while longer to adjust to this medicine, I think.

Anyway, lots of development updates below. I know parts of this don't make for easy reading, so if you'd like me to explain any part in more detail, I'm happy to do that :)

Not everything that's been updated/finished is below; I'll try to include them next time, or in an additional update in a few days or something.

Rate limits: searches, submissions and CDN requests

I’ve implemented rate limits for artwork submissions; they still need a bit of polishing, but the general idea is that an artist is limited to posting X artworks per day and Y artworks per week, e.g. 2 per day, 5 per week (those aren’t the actual numbers, they’re just to give an idea). I might also need to implement a counter for submissions in themselves, rather than just counting submissions in the database, to avoid people doing delete-reupload spam, but that seems unlikely to be needed.

I still need to do search rate limits, but that should be fairly simple to implement. CDN limits involve using AWS WAF (the firewall for CloudFront’s CDN), which costs money but will be necessary. It means I can limit the number of image requests a given client makes per 5 minute interval, for example a max of 100 big images, and a separate rate limit of e.g. 2000 small images. The ideal point of this is to not hinder actual users, but make DDoS attacks and scraping bots less viable, as CDN costs can rack up very fast indeed.

Lambda layers, maintenance improvement - STS investigations, VPC endpoints

As part of making the site easier to maintain, I’ve changed some of the Lambda functions to have layers instead of all being bundled up in big packages. It means e.g. the image resizer code no longer has the Sharp image library bundled with it, and instead AWS loads it alongside the code at runtime as a separate “layer”, which is easier to maintain.

A lot of the site’s PHP code has been restructured to use AWS Parameter Store to store credentials (so that most credentials don’t need to be stored in PHP files). For one, it’s easier since those files can’t go into version control, and also it means that I can have one set of Parameter Store credentials per region, and use that to give Test/Local/Live environments their own credential sets. I tried doing this for the Lambda functions, but there are complex VPC networking problems to overcome to use this (you can do it, but it costs $8/month per environment, as you need a VPC endpoint to access the parameter store or the STS role assuming service). An unneeded pain, plus it adds a little latency to the functions, so not bothering with that.

Multiple submission notifications

Notifications are now implemented for multiple submissions (e.g. when an artist uploads 5 submissions at once, rather than 5 images and one submission). The per-week limits on submissions should ensure that notification spam in this regard doesn’t become an issue.

Artwork submission improvements - S3 folder for temp uploads, CDN for subscribed content

One very minor security flaw was bugging me: the old system of submitting an artwork involved displaying the image the artist uploads in the submission form. Since this image must be accessible from the webserver, it meant that *theoretically* the full size image was therefore publicly visible, even though the chance of actually guessing the URL in the submission window is next to zero. Still, “next to zero” is always a dangerous assumption in security terms.

I’ve therefore changed all of the artwork submission code, which was a *lot* of work. It now uploads images to a temporary folder that is cleared frequently, and resizes them before displaying them - the full size artwork the user uploaded is never publicly visible in any sense.

CloudFront: 4K image cache invalidation

This comes in the context of the above S3 stuff, and also this thread I wrote earlier: https://twitter.com/antsstyle/status/1636991304235118595

I realised that by having “private S3 buckets” that required signed URLs to access e.g. 4K images, there was a major caching problem. Because the links are unique, browsers don’t cache them: this means 4K images would constantly be being downloaded instead of cached, which would make for some seriously heavy CDN costs.

I investigated, and the solution I have is to copy 4K resized images to a public bucket when an artist subscribes, and delete them if they unsubscribe (or choose not to allow 4K images, they can change this setting). This also means a bit of extra CloudFront work; since the CDN will still have cached copies, when the artist’s subscription runs out or they choose to disallow 4K images being displayed, we need to send a cache invalidation to CloudFront telling it to delete the cached files for that specific artist’s 4K images. Otherwise, their 4K art would remain accessible for some hours after they disabled 4K display in their settings.

Support queries, reports - in progress

One of the major outstanding things to do is building a system for enquiries (e.g. non users asking stuff) and support (users asking about site issues, or reporting other users, etc). I’m part of the way through this; technically it’s fairly simple, but I had to make some decisions about how e.g. non-user queries are handled, since they can’t log in.

For now, it’ll work by responding to the person’s specified email address, and further replies will involve going back to the site form and sending another query. For users, it will work similarly to the site’s private messages; since users can log in, we can show a conversation without issues, which is a lot easier. I’m still working on the email templates for both the former use case and for activation emails, but it shouldn’t be a big deal… just one of those things to get done.

Back to top