Tuesday, 5 January 2021

HTTP 403 - Unauthorized - REST API being hexed ...

 A colleague had an interesting challenge this AM, with a REST API authorisation failure.

The API call, using the POST verb, should have just worked, but she was seeing: -

{
   "message" : "Unauthorized",
   "statusCode" : 403
}

From an authorisation perspective, the cURL command was using an environment, ACCESS_TOKEN, which had been previously set via a prior Bash script, via this: -

—H "authorization: Bearer ${ACCESS_TOKEN}"

Having copied the command that she was running, I saw the same exception even though similar POST verbs worked for me.

After much digging, I realised the problem; her cURL command should have included this: -

-H "authorization: Bearer ${ACCESS_TOKEN}"

Hmm, looks pretty identical, right ?

WRONG!

For some weird reason, the hyphen ( - ) in my colleague's command wasn't actually a hyphen.

I ended up using hexedit to dig into the failing command: -



where those strange-looking period ( . ) symbols were actually: -

20 E2 80  94 48 20

rather than: -


20 2D 48  20

So the failing command had hex E2 80 94 whereas the working command had hex 2D, before the letter H ( which is hex 48 ).

I'm guessing that this was a copy/paste-induced bug, but it was fun digging .....


No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...