After a year of using the free tier AWS instance we had to decide what an inexpensive alternative is. We decided to stick with the Sydney micro instance and decided to get a three year reserved instance.

Requirements

Over the years we had several requirements.

Gallery Access Restrictions

We never wanted the world to have access to our galleries. We added basic authentication to prevent people from accessing the galleries unless the new the simple user/password combination.

We also did this to prevent unpredicitable download volumes which would have cost us a lot before 2005 (or even later).

But mostly we chose to hide the galleries behind authentication to make sure that pictures of our friends and their families are not publically available.

While we do not require extreme levels of security, we want to prevent access by strangers.

Our galleries are for us and our friends.

Storage

We only have limited space on our micro instance and before on our hoster and we don’t want to spend a lot on storage, but we create more galleries and we want to be able to generate bigger images than our current maximum 900 pixel dimension. At the moment Martina is also making older galleries available. Our previous usage was about 1GB of images. Adding 1600 px images and a few more galleries increased this to 6GB

Speed

Markus wanted things to be faster. His WordPress tests with CDNs in 2014 were OK, but the set up was not optimal and he stopped using the CDN after a few trials. Now we are back to going through a CDN, but the W3 Total Cache plugin is annoying. Either way, it wont help us with our galleries since we would have to handled that our selves.

Gallery 2.0

Using a CDN is not immediately feasible with our approach of sharing galleries with friends. CDN policies for signed URLs would make administration more evolved. We would have to always remember what images we. It would also mean that our gallery.php would have to do more on the server side. Instead we considered a different approach. Storing images on S3 would be preferred, but we while we can restrict access by the CDN it again would not solve the access control via the CDN.

Hashes Instead of protecting all images from access, we use hashes for our file name like this one: http://d3t223w3wiedbz.cloudfront.net/2009/900/cd69e7276b9e6a22320b83259348fc56aff37de23014b3e50fb309b628580292.jpg

The hash is based on the original photo before it becomes resized to different dimensions or into a thumbnail or map icon.

Hash Advantages

• No one can guess a photo’s name
• No one can browse images
• A hash will ever change unless the original image changes. This is great news for caching.
• As long as we do not allow list access we can store images in e.g. s3 and all images are still “safe”
• We can use a CDN without having to restrict access further

Hash Disadvantages

• It is not clear what the original image for any image is
• Misconfiguration is possible and might expose all images. the time to guess file names might be going down to give some one a chance to guess several file names.

gallery.xml

The only place were hashes are listed and mapped to the original file names is in the gallery.xml of each gallery. Therefore we still have to secure all gallery.xml files or we would essentially give access to all files.

At the moment we handle this the same way we did before with basic authentication but the next evolution will come.