I have a Bash script which executes the following command on my Synology. It's supposed to use the Synology API to save my YouTube stream key to the Synology's "Live Broadcast" widget. It's works fine most of the time. (Note that the cookies file is dealt with in a separate command which pre-authenticates with the API)

This works fine, the full key is saved to the widget:


However, if the first four digits of the "key" are decimals (no letters) then it has a weird failure mode; only the first four digits get saved. For example, this causes the widget to merely save "1234" as its key, instead of the whole key:



Comparing two similar commands, I discover that the first digit group of the key must contain at least one letter for it to save correctly. Examples:



Is this some kind of a bug in Wget where it's not interpreting the parameters correctly? Some weird thing about how it processes command line parameters that I don't understand? I've sometimes seen numeric representations in Powershell get weird where it interprets a number as Octal if it start with a zero in some cases. I wonder if this is something along those lines like that?

Because if it's not Wget, then it must be a bug in the Synology API. I'm just wondering if anyone recognizes this as a known issue in Wget or something.

Note: Every time, the API returns "{"success":true}", even in the failure cases. So the API thinks I'm submitting a good string every time. Also, URL-encoding the key, either by replacing the dashes with %2D or even replacing every digit with a URL escape code, doesn't solve the problem. Surrounding the key with single quotes, like &key='1234-1234-1234-1234-1234' causes the full key to be saved, but also the single quotes get saved too, so that isn't a successful workaround.

Any ideas?

Thanks!

Could just be something with whatever command shell is being used to interpret that line. Guard against that by using single-quotes instead of double-quotes around the URL.

Good idea. Tried it, and I get the same results whether I use single or double quotes around the URL.

The more I think about it, the more it's got to be a bug in the Synology API rather than a bug in wget or the shell. Because even when I URL-encode every digit of the key, I get the same result.

Don't suppose you have anything else that runs Linux that you can try? Maybe a Raspberry Pi or a Linux live USB stick (assuming they have wget)? Would be interesting to see if the issue persists on a different platform.

If you suspect a bug in wget, try the same thing with curl.

Wget doesn't really parse anything after the third slash '/' character. So, yeah, perhaps a bug in the Synology stuff.

*smacks forehead*

Of course! Idiot me. I don't even need some other system. I just need a web browser. Everything is in the URL, so I'm able to just pop the URL into any web browser (replacing Localhost with the address of the synology). Guess what? Same problem reproduces. It's definitely not related to any sort of command line parsing, it's absolutely a bug in the Synology API. I'll report it to them.

Now I just have to code a workaround. I have a few options, but they all depend on YouTube not doling out keys which start with four decimal digits very frequently.

Since the issue was in the process of reproducing a second time this morning, I was able to code my workaround into place while the problem was still happening, and then watch it correctly detect and fix the problem.

The detection is: After the script sets the key, instead of assuming that it set the key correctly, it rechecks the key to see if it really did set it correctly. If not, then the script throws away the YouTube stream and creates a new one from scratch, hopefully the new stream won't have the bug-inducing first four digits.

This has the potential to get into an infinite-correction loop if YouTube keeps repeatedly doling out keys that start with four decimal digits. But that's not something I can fix on my end. Hopefully I can get Synology to fix their root cause and they'll push out an update to Surveillance Station so that my workaround code never gets hit.

I got a response from my bug report to Synology.

They suggested a workaround of putting double quotes around the key, something I hadn't tried. I had already tried single quotes around the key like this:

&key='1234-1234-1234-1234-1234'

But that had only partially worked; the full key did save, but it also saved the single quotes into the key itself, thus making the key invalid. I hadn't thought to go forward and try double quotes around the key. Turns out that fixes it.

Though instead of doing double quotes in my script (since other parts of the code which touch that string are already using double quotes as other delimiters), I am using %22 instead, which also works successfully:

&key=%221234-1234-1234-1234-1234%22

Can't help thinking that something's playing fast-and-loose with parsing that query string -- if it looks like a number, it's a number, if it's quoted, then it's a string.

I wonder if there's any scope for misusing that parsing -- like, if the server is nodejs for example, throw a Javascript eval in there somehow...?

I'll bet there's a command somewhere in the API backend code that simply assigns a variable to whatever is found after "&key=". Whatever language they wrote it in, the variable assignment is interpreted with that language's rules for deciding if it's a number or a string. So there's probably a statement something like this in the code:

finalKey = parsedKeyString

The fact that it allows the variable "finalKey" to freely transmute between an integer and a string means that the API backend is written in some sort of scripting language with dynamic typing, rather than a compiled language with static typing. It's a bug where the programmer assumed that it would always stay a string, and they forgot that their language is dynamically typed.

You know, I'm going to say so in the bug report, because the guy responding to the bug report is trying to tell me that the doublequotes are required by the API (they're clearly not) and I think they might be planning to close the bug as Won't Fix.