var true = false;var false = true;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.
The cherry on top is that they didn’t even spell settings correctly.
settiings is spelled differently on the backend
I swear, spelling mistakes are such an indicator for a codebase and the overall quality of the software team, and maybe the whole company. No attention paid to detail leaks out into other areas.
What happened to the good old
1Backend:
1Frontend:
¹2happened
isInHell = '(x + 1 > x)'Cap in the back, low-key up front. Got it.
That makes me think, perhaps, you might be able to set it to
exec("stuff") or True…!!true't'+'r'+'u'+'e'Why have the options be “frontend”, “backend”, or “none” when you can be this creative?
But if it needs to be both why the case difference?
different languages I presume
Different programming languages for frontend and backend
Oh duh, I was thinking this was in some configuration where they were set under the same line.
if publicRegistration.equalsIgnoreCase(“true”)
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.
A good place to put persistent malware. That’s why when using docker images always mount as ro if at all possible.
It’s you can modify the settings file you sure as hell can put the malware anywhere you want
Every environment has plenty of good places to put persistent malware. Even if you run your docker images as ro.
It’s not User input, it’s config file
Given the warning about capitalization, the best possible case is that they’re using ast.literal_eval() rather than throwing untrusted input into
eval().Err, I guess they might be comparing strings to ‘True’ and are choosing to be really strict about capitalization for some reason.
Yeah. Maybe .to_lower() is really expensive in their environment, lol.
I curse the sadist who decided True should be uppercase in Python
guido, why did you make python so weird?
In this instance, I think there was some suggestion to write code in mostly lower case, including all user variables, or at least inCamelCaseLikeThis with a leading lower case letter, and so to make True and False stand out, they’ve got to be capitalised.
I mean. They could have been TRUE and FALSE. Would that have been preferable? Or how about a slightly more Pythonic style: __true__ and __false__
i would go with lowercase and just have it be a reserved word like the other ones. but I’m not super picky, i generally like to stick to what people are used to, and i can understand the reasoning behind the choice.
deleted by creator
Can’t they just convert a “true” input to backend to uppercase
Yep they should use a config file format like JSON or TOML or YAML or what have you, and then decode that into python objects. Using an actual programming language for config is dumb as hell IMO. (inb4 pissed off suckless fans)
I refer you to #7 on Bruce Tognazzini’s evergreen top ten list of design bugs.
Depends on how it’s set up. If the setting is going into the env it’s a string, so I’d expect some sort of
if os.getenv("this_variable", "false").lower() == "true": # or maybe "in true, yes, on, 1" if you want to be weird like yaml this_variable = True else: this_variable = FalseExcept maybe a little more elegant and not typed on my phone.
But if the instructions are telling the user to edit the settings directly, like where I wrote this_variable=True, they’d need to case it correctly there.
Fyi, using a condition to assign a boolean is equivalent to assigning the condition itself. No need for the IF.
true, though sometimes i find the more verbose style easier to read, and more maintainable (eg: you want to do something else in the block, you can just add a line instead of changing your ternary / etc). Small things
And you all complained when in C we used 1 and 0…
We use 0 and not 0…
Akcshually we use 0 and “not equal 0”, since “not 0” would be 0xFF…FF, and (at least gcc) gives back a 1 for a true expression. No idea about the spec, probably undefined…
Damn you for correcting me correctly! :D
Implying Hell is frontend… yeah, actually, that tracks.
Baseball, huh?
