So we need to be careful with upper- and lowercase. Meanwhile the docs: > setiings
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.
There’s a double-i in “settings” in the documentation screenshot
That’s what I get for having sucky vision.
That why you only sidekick. MC need perfect vision.
They specifically said “this is not a typo”!!!
Is the backend Python and the frontend JavaScript? Because then that would happen and just be normal, because Boolean true is True in python.
Searching for the phrase, documentation matches for Taiga so maybe you're right!
Taiga (project management) - Wikipedia

Probably, but if you’re interpreting user inputs as raw code, you’ve got much much worse problems going on, lol.
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.
Every environment has plenty of good places to put persistent malware. Even if you run your docker images as ro.
It’s you can modify the settings file you sure as hell can put the malware anywhere you want

It’s you can modify the settings file you sure as hell can put the malware anywhere you want

True. But a code settings file still carries it’s own special risk, as an executable file, in a predictable place, that gets run regularly.

An executable settings file is particularly nice for the attacker, as it’s a great place to ensure that any injected code gets executed without much effort.

In particular, if an attacker can force a reboot, they know the settings file will get read reasonably early during the start-up process.

So a settings file that’s written in code can be useful for an attacker who can write to the disk (like through a poorly secured upload prompt), but doesn’t have full shell access yet.

They will typically upload a reverse shell, and use a line added to settings to ensure the reverse shell gets executed and starts listening for connections.

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.

ast — Abstract syntax trees

Source code: Lib/ast.py The ast module helps Python applications to process trees of the Python abstract syntax grammar. The abstract syntax itself might change with each Python release; this modul...

Python documentation
Yeah. Maybe .to_lower() is really expensive in their environment, lol.
Can't they just convert a "true" input to backend to uppercase

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 = False

Except 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
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.

www.asktog.com/…/10MostWantedDesignBugs.html

The AskTog Bug House: Ten Most Wanted Design Bugs

My thought exactly. Which made be think about potentially setting the backed one to exec(“stuff”) instead…
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.
But if it needs to be both why the case difference?
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.
different languages I presume
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.
Hear me out, what about using JSON to store the configuration in the Python backend?
You need to use as many different formats as possible, otherwise you look unprofessional

I like your idea, but hear me out:

A Python file for configuration is the best way to guarantee that any friendly code I write to help the user with config usually won’t execute. And I hate my users.

That makes me think, perhaps, you might be able to set it to exec(“stuff”) or True
Could be worse. At least it’s documented
To me the biggest problem, that AI might solve is documentation.
Have you tried to use AI for documentation? It’s pretty shit.
I’ve had pretty good experience with using AI to find what I’m looking for in documentation, especially if the docs are in context
I think they mean having an AI read code and then write documentation for it. Not having an AI read documentation.
I’ve used AI to give me a good enough guess that I know the right keywords to search for too find the documentation.

Have you tried to use AI for <thing>? It’s pretty shit.

Translation, proofreading, summarizing, brainstorming, boilerplate code, protein folding…

protein folding

We’re at the point where, due to how tech services work, I think a lot of people think AI === LLM

How about this:
Humans (or humans assisted by AI) write documentation
Users (devs includes) can either choose to read the manual the old fashioned way or utilize it like a sort of swagger api documentation to give

  • Information to a question (How to do x)
  • Provide a general example
  • (Assuming it’s used with an IDE or has information about the project) Provide a personalized example on the implementation.
  • What happened to the good old 1

    Backend: 1

    Frontend: ¹

    if publicRegistration.equalsIgnoreCase(“true”)
    isInHell = ‘(x + 1 > x)’
    Fun and games till x overflows.
    LOL but it was ’ x + 1’ not ‘x += 1’ tho.

    We don’t know what value X has. If it isn’t initialised it could have any value including the maximum. Then it would overflow.

    But let’s be honest, that is unlikely.

    Why have the options be “frontend”, “backend”, or “none” when you can be this creative?