just another web log

13 Nov 2022:
418 i am a teapot short and stout

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


13 Nov 2022:
S3 says yes computer says no

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

12 Nov 2022:
dungeon tape for hacking the ancients

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.

Screenshot of ancient dungeons loading screen

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

Screenshot of ancient dungeons weapons

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.

Screenshot of ancient dungeons slime

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.

Screenshot of ancient dungeons chest

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.

Screenshot of ancient dungeons chest open

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

Screenshot of ancient dungeons slime boss

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

Screenshot of ancient dungeons pendulums

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

Screenshot of ancient dungeons map health coins keys pouches marks

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

Screenshot of ancient dungeons knights

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.

Screenshot of ancient dungeons wizards

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

Screenshot of ancient dungeons milestones

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 !

12 Nov 2022:
hacking an escape room in the real world

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 :)

01 Nov 2022:
an akylosaurus called muffin

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.

blocky mesh of ankylosaurus - blender screen shot

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

ankylosaurus mesh - rough - blender screenshot

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

ankylosaurus clay blender screenshot

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

ankylosaurus UV matcap blender screenshot

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

ankylosaurus Jade matcap blender screenshot

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

muffin the ankylosaurus 3d printed photo

muffin the ankylosaurus 3d printed top photo

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.

loading results, please wait loading animateloading animateloading animate
[More tags]
rss feed



flog archives

Disclaimer: This page is by me for me, if you are not me then please be aware of the following
I am not responsible for anything that works or does not work including files and pages made available at www.jumpstation.co.uk I am also not responsible for any information(or what you or others do with it) available at www.jumpstation.co.uk In fact I'm not responsible for anything ever, so there!