f-log

Just so you don't forget, HTTP status code 418 I'm a teapot really exists.

refs

• Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) RFC2324

• Trojan Room coffee pot page on Wikipedia

• The Trojan Room Coffee Machine

• The Trojan Room Coffee Pot A (non-technical) biography

When you load a web page on your computer a number of things are happening.

The list is long and mostly unimportant to you for the web page to load correctly. It just works .

Except when it doesn't.

I was working on project that allowed a user to select an image and have it applied to another image and then saved. A sort of design your own product but with predefined options.

The technology was fairly simple. Javascript in the web page would list all the selection options and once selected apply them and save the results.

When run in the development environment this all worked fine. When deployed to the staging environment it worked fine.

The client was able to set up the staging environment for testing on a cloud server and show that the functionality worked in principal.

Perfect, job done, pat on the back for everyone.

Except there was a small problem. The number of images the client wanted to use and the number of images that users were creating was growing and was expected to accelerate. Storing all of these on the cloud web server was going to get expensive.

Amazon cloud services has a offering called S3 that is ideal for this sort of project. You run your web server over here and then outsource all your file storage to S3.

The code was changed to save all the files in S3 and tested. The tests showed the images were now saved in S3 but nobody checked the functionality.

The developers continued in their development environments and used old images available on their machines. Because, why not? They are just images.

When the updates were pushed to staging the client noticed that something was not right. Sometimes the images would be applied correctly and sometimes not.

The developers tested the staging environment and got consistent results, but different from the client. Most of the time selecting the image twice would fix the problem.

Switching the developers to use a local environment that more closely matched the staging servers brought more misery, as no one seemed to be able to pin down exactly what the problem was or to consistently repeat it.

Many ideas were put forward and tested, but there was still no consistency. Some tricks worked sometimes for some users.

The issue turned out to be Chrome browser specific. This included Microsoft Edge, which is based on the same engine.

It went something like this;

The browser would send a request to S3 asking for an image and S3 would reply with the image. All, so far so good.

Then the user would select the image they wanted and the code would try and apply the image.

This is were it went a bit wonky. You see, to avoid getting files that you have already download, your browser keeps a cache. If you request the same file again then it gets it from the cache instead of bothering the server. There are a number ways caching and cache expiry are done, but it is not relevant here.

So the code asks for a copy of the image to apply and the browser very helpfully says "no problem, I have that here, here you go". Sounds sensible, if it wasn't for web browser security.

To stop web pages from just pulling files from any old place and doing what they liked with them, both the browser and and the file server have to accept the intent.

The way they handle this is through bits of information sent to the server with the request for a file and bits sent back with the file. These are called headers.

With everyone in agreement everything just works and it would have if everyone was using Firefox as a web browser.

What was happening was Chrome was making the original request to list the images correctly. Headers were sent and correct headers were received. But, when the image was requested again and the cache was used NO HEADERS were being included and the SECURITY just stopped everything dead.

Computer says No!

The developers would often be using Firefox or Chrome developer tools which turns off caching . And sometimes people would reload the page or interact with it in a way that would invalidate the cache. Not to mention, local images, http vs https addresses and myriad of other things that could have been causing an issue.

The solution was to force the browser to request the images without using the cache. Which is fairly straight forward.

Instead of asking for image1.jpg you request image1.jpg?cb=999 were the 999 is a random number. The file server cannot know if the request will be a straight forward file called image1.jpg or something generated by the random number.

What is interesting is that nobody at any point expected Chrome to have known bug that is marked Wont fix(closed) by the Chrome development team.

Write up about the technical details. hacksoft.io...handle-cors-error-in-chrome

A slightly different hack this time and an opportunity to talk about my favourite game on the Oculus Quest 2.

I found Ancient Dungeon on applab a couple of years ago as a free demo/beta and loved it. Played it to death.

So when I found a full release version I had to have it!

Ancient Dungeon is an odd one. It looks terrible. Unless you are a Minecraft fan.

But hidden beneath the surface is a game that is well worth your time.

The more you play the more you unlock. You start with a throwing knife and sword, but can upgrade to a crossbow. These weapons themselves can be upgraded using Beast Blood that you get from defeating the end of game boss.

There is a huge number of diverse enemies. From slimes to ogres, from spitting plants to flying bats, from wizards to laser diamonds. And each one has multiple variants and strengths.

Which brings me to main marmite point of Ancient Dungeons. It's random, like really really random. The dungeon layout is random, the room contents are random, the enemies are random, the treasure is random and the power-ups are random.

This can make for some insanely varied game plays. From high powered weapons and lots of health to abilities that have non-obvious drawbacks.

There are potions, marks , shops and just straight up random abilities. But unless you played enough you may never see some of them.

Each area has an end boss that is (you guessed it) random.

The different themed areas have (you guessed it) random traps, hidden rooms, more traps and treasures.

Being VR, you can turn your wrists and see, the map, your health, coins, keys, pouches and marks .

Each enemy and each challenge require a level of understanding. This encourages you to return many times to try another technique. Knights have a specific way of moving and attacking.

Wizards fire glowing pink rings, but being VR you can duck behind a pillar.

Right, now I have introduced a very small number of the features of Ancient Dungeon, I can talk about the hack

One of the finds in the dungeon is challenge rooms. Sometimes they are tricky traps, other times exploration and other times you have to climb.

I came across one room where the climbing handles were too far apart to reach ...

But this is VR. What if I really really stretch or put one controller under my foot ...

This got me so far, but the solution was to tape the trigger down while grabbing a climbing handle and then climbing (in the real world) on to a chair.

Don't do this. I fell off and falling in real life while wearing a VR headset is not fun!

It did work though :)

Ancient Dungeon gets bug fix and content updates often, so hopefully no one else is forced to do this.

Current plays is 346 with 40 completions. Lots of reasons to go back and play again !

Time for a brief intermission ... for hacking an Escape Room!

This was my second Escape Room in the real world and it took place a couple of hundred miles away from the first. I was also with a completely different team.

The theme was around a biological outbreak and the vaccine has been hidden by a recently murdered scientist.

The single room had various cabinets, shelves, a desk and various oddities.

But my eye was drawn directly to the open Mac-book on the desk that was requesting a password. The screen was open with Safari browser pointing at a local web page. This indicated that the password would be checked in Javascript, no server based database ...

A quick opening of dev tools and I could see ... well, not a simple

const password = 'topsecret'
if (input === password) {
    window.location = 'secretpage.html';
}

Instead the password was calculated from a number of minified methods and variables.

So they had made some effort to stop the casual hacker.

Not good enough!

There was still a compare user input to password . Just a quick copy and paste of the calls it was making into the dev console and ... Bingo! one decrypted password.

Enter that on to the page and ...

There was no "secretpage.html", instead it was a hidden div.

So I didn't need the password at all :)

The newly visible div shows a lock combination. Now, at the beginning the staff had explained how to use a tumbler padlock ...

But no one in the party could get it to work, so we assumed it was wrong.

It was not wrong. That was supposed to be the final puzzle in the room and we did find the password through normal means eventually.

Then we still couldn't get the lock to open with the same combination.

In the end we lost the game and then the staff member showed how it was the correct lock combination :(

Still, we all had fun and then went for chocolate frosty milkshakes :)

Back in July the D&D campaign I was on encountered some dinosaurs (like you do).

We defeated the ones that attacked us and were left with a non aggressive ankylosaurus. This was quickly named "Muffin" and tamed. It was also used as a pack horse to carry a boat, that one member of the party was convinced we would need eventually.

Spoiler, we never needed the boat.

It tickled my fancy to to try and model this ankylosaurus and a boat for it to carry.

I did the following without any reference material, so it's a bit stylised, but everyone enjoyed the output!

I knew exactly how I was going to tackle this, so I started with an incredibly blocky base.

A quick Sub Surf modifier and some light sculpting with mirroring turned on.

Some more sculpting detail and a quick, simple boat shape.

My favourite UV MatCap view in Blender. Will all those details come out in the final print?

And a quick Jade MatCap because ... well, it looks nice!

I still only have black PLA filament for the printer so these are a little dark.

There you have it, lots of detail and I love all the bone extrusions in tail.

Quick note: This is not and was never intended to be a photo realistic ankylosaurus. Just a bit of fun.