It may just be the example that's not correctly formatted, but the other (working) example does in fact escape the double quotes in the JSON. I guess, depending on how forgiving the used language is with quoting, that could also be the source of the error?
So if this is indeed the API they're using it's not only literal "\\n" but also "\\r\\n", no "POST", and no body at the end.
juancn 11 days ago [-]
Yeah, I'm stuck here.
Another thing that's really broken is the last string with unescaped quotes.
Not sure how to interpret that unless theres a `:` (colon) operator.
nebster 11 days ago [-]
I... still don't understand the issue. It looks like both examples in the table would evaluate to the same thing. Am I missing a stray "\n"?
kichik 11 days ago [-]
Not exactly the point of this article, but it would be cool if APIs like this can return the expected signed string for debugging. It would have to be properly limited for security. But if the API is expecting non-standard signatures, it could help developers with better debugging tools.
lillesvin 11 days ago [-]
Given that you can't infer the error from simply looking at the signature string, I don't see how having the expected string rather than a simple "OK" or "mismatched signature" (as you get now) would make a difference?
kichik 11 days ago [-]
You can save the expected string to a file, save your string to a file, and run diff on a hexdump of both. Even without hexdump, you should see the difference between "\n" and "\\n" in properly escaped output.
lillesvin 10 days ago [-]
But the returned signed string will be an HMAC-SHA256 hash, won't it? Then there's not going to be any '\n' or '\\n's in there. Only thing you'll be able to tell is if it matches your hash or not, in which case 'OK' or 'not OK' will work just as well.
Or am I misunderstanding you?
kichik 9 days ago [-]
You are indeed misunderstanding me. I am talking about returning the entire string to be signed. Not the result of the signature.
lillesvin 8 days ago [-]
Ah, my bad. Sorry.
But couldn't you then just make the call to an echo service (like HTTPbin) or simply dump the request when you send it?
kichik 8 days ago [-]
The echo server will have no knowledge on how to construct the string to be signed.
lillesvin 8 days ago [-]
But neither does the actual server. HMAC only verifies that the message is from whoever it claims to be from and that it is intact. It won't know what you intended the body of the request to look like.
jojomodding 11 days ago [-]
Perhaps this article was written by the same AI that failed to understand what it was supposed to do in the first place? The post doesn't make a lot of sense and the writing seems fishy. I still don't understand what was wrong with he first code.
snowfield 11 days ago [-]
I often find myself clearing the context when dealing with llms to get a fresh take. Often it just has so much context reinforcing its previous decisions.
Not sure if the author tried to just start a new thread. But anyway, for now you always need to keep an eye on these things and manage it if it follows red herrings or ends up in some logical loop
Sidenote : newlines is one thing tat can be quite tricky for llms in general.
DylanSp 11 days ago [-]
Echoing the others who say they can't understand the bug/difference; only thing I can think of is that the input string needed the escape sequence for a newline in it? So the correct code would be written as
"POST" + "\\n" + ...
fernly 11 days ago [-]
agree, I feel dumb but don't see subtle issue.
Also when copy/pasting into Python to try it, I got an error because \“ is in fact U+201C not an ASCII quote. (Surely that's not the subtle issue?)
thehappypm 11 days ago [-]
tl;dr: custom, naïve
Concatenation formatting implementation can cause bugs
Rendered at 05:23:48 GMT+0000 (Coordinated Universal Time) with Vercel.
However, there's a quoting error in the failing example where the double quotes in the JSON body aren't properly escaped:
It may just be the example that's not correctly formatted, but the other (working) example does in fact escape the double quotes in the JSON. I guess, depending on how forgiving the used language is with quoting, that could also be the source of the error?Another thing that's really broken is the last string with unescaped quotes.
Not sure how to interpret that unless theres a `:` (colon) operator.
Or am I misunderstanding you?
But couldn't you then just make the call to an echo service (like HTTPbin) or simply dump the request when you send it?
Not sure if the author tried to just start a new thread. But anyway, for now you always need to keep an eye on these things and manage it if it follows red herrings or ends up in some logical loop
Sidenote : newlines is one thing tat can be quite tricky for llms in general.
Also when copy/pasting into Python to try it, I got an error because \“ is in fact U+201C not an ASCII quote. (Surely that's not the subtle issue?)