So we need to be careful with upper- and lowercase. Meanwhile the docs: > settiings
Yes, the settiings are different than the settings. You also need to be careful with those.
had to use a different spelliings at backend and frontend, otherwise it wouldn’t work.
no, settings = settings but settings != Settings, as we all know.
Is the backend Python and the frontend JavaScript? Because then that would happen and just be normal, because Boolean true is
Truein python.Probably, but if you’re interpreting user inputs as raw code, you’ve got much much worse problems going on, lol.
[...]®ister=import os; os.system("sudo rm -rf /"); return TrueHey, that’s my username too. Or it was going to be, while the site was still up.
What a coincidence!
I guess I’ll wait for the site to come back, and see if it’s still available…
It’s the settiings file… It’s probably supposed to only be written by the system admin.
Could be worse. At least it’s documented
To me the biggest problem, that AI might solve is documentation.
Glorious. I remember some hilarious nonsense in an API where the devs I worked with hadn’t known they could just use boolean in JSON and had badly implemented it through strings, but this… This is amazing!
At my last job we had a lot of old code, and our supposedly smartest framework people couldn’t be bothered learning front end properly. So there was a mix of methods for passing values to the front end, but nobody seemed to think of just passing JSON and parsing it into a single source of truth. There was so much digging for data in hidden columns of nested HTML tables, and you never knew if booleans would be “true”, “TRUE”, “1”, or “Y” strings.
Never mind having to unformat currency strings to check the value then format them back to strings after updating values.
I fixed this stuff when I could, but it was half baked into the custom framework.
A system I work with gives all keys a string value of “Not_set” when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.
Of course, it’s up to individual developers to never forget to set a key to “Not_Set”. Also, they forgot to standardise capitalisation and such so there are all sorts of variations “NOT_SET”, “Not_set”, “NotSet”, etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).
