5 ms·
Thanks, I hate it. While it's nice syntactic sugar, the difference between an SQL injection vulnerability and a properly parametrized query is now a single lett
by jbaiter 1y ago
Thanks, I hate it. While it's nice syntactic sugar, the difference between an SQL injection vulnerability and a properly parametrized query is now a single letter that's easily missed
- TekMol 1y agoI guess that is a misunderstanding on your side, about how templates work. Less hate and more love might help to avoid this type of hotheaded misconception ;-) Why do you think changing a letter would cause a vulnerability? Which letter do you mean?
- hyperbovine 1y agoOP is referring to swapping t with f.
- TekMol 1y agoThat would result in a string passed to get() and raise an error as get() operates on a template, not on a string.
- baegi 1y agoexcept if get() can also accept a raw string, which is likely
- orphea 1y agoWhy would it?
- mcintyre1994 1y agoNo sane library is going to do that. If they do let you pass a raw string it should be a different function with the risks clearly documented. The thing this replaces is every library having their own bespoke API to create a prepared statement on their default/safe path. Now they can just take a template.
- crazygringo 1y agoHow about every library that wants to preserve backwards compatibility? Or are you suggesting that e.g. every database module needs to implement a new set of query functions with new names that supports templates? Which is probably the correct thing to do, but boy is it going to be ugly... So now you'll have to remember never to use 'execute()' but always 'execute_t()' or something.
- WorldMaker 1y agoYou don't have to remember it, you can use deprecation warnings and lint tools to remind you. (Until eventually the safe API is the only API and then you really have nothing to remember.)
- mcintyre1994 1y agoI’d assume their current safe function isn’t taking a string, and is taking some sort of prepared statement? So they could have it take either their prepared statement or a template, and deprecate their prepared statement. If a library has functions taking a string and executing it as SQL they probably shouldn’t make that take a template instead, but I’d hope that’s a separate explicitly unsafe function already.
- crazygringo 1y agoFor sqlite3, it absolutely takes a regular string. If you want to substitute parameters, you put a '?' in the string for each one, and provide an additional (optional) tuple parameter with the variables. So no, there's no explicitly unsafe function. That's my point.
- mcintyre1994 1y agoGotcha. I’d guess they’d want to deprecate that function and create a new one that only accepts a template then, which is definitely annoying! I figured they’d already have more separation between prepared and raw strings which would make it easier.
- codesnik 1y agof'' vs t'' probably.
- tannhaeuser 1y agoWow that's only slightly better than using the lowercase letter L vs the digit 1 or letter O vs zero to convey a significant difference.
- melodyogonna 1y agoThose are two different types
- deleted 1y ago[deleted]
- baggiponte 1y agoType checkers to the rescue ahaha I think db.get could also raise if the type does not match?
- JimDabell 1y agoThe t-string produces a Template object without a __str__() method. You can’t mistakenly use an f-string in its place. Either the code expects a string, in which case passing it a Template would blow it up, or the code expects a Template, in which case passing it a string would blow it up.
- politelemon 1y agoAnd I'm guessing lots of code will expect strings to maintain backward compatibility.
- Mawr 1y agoI'm guessing no existing functions will be extended to allow t-strings for this very reason. Instead, new functions that only accept t-strings will be created.
- xorcist 1y agoThere's an obvious risk here, same as with strcpy (no, strncpy.. no, strlcpy... no, strcpy_s) that documentation tends to outlive code, and people keep pasting from tutorails and older code so much that the newer alternatives have a hard time cutting through the noise. I would argue that as bad as some w3schools tutorials were, and copying from bad Stackoverflow answers, going back to MSA and the free cgi archives of the 90s, the tendency of code snippets to live on forever will only be excarbated by AI-style coding agents. On the other hand, deprecating existing methods is what languages do to die. And for good reason. I don't think there's an easy answer here. But language is also culture, and shared beliefs about code quality can be a middle route between respecting legacy and building new. If static checking is as easy as a directive such as "use strict" and the idea that checking is good spreads, then consesus can slowly evolve while working code keeps working.
- sanderjd 1y agoIt's pretty common for Python libraries to deprecate and remove functionality. It makes people mad, but it's a good thing, for this reason.
- yxhuvud 1y agoAlso I wonder how easy it will be to shoot oneself in the foot. It may be easy to accidentally make it to a string too soon and not get the proper escapeing.
- scott_w 1y agoThat’s a library author problem, so it’s less likely since library authors tend to be fewer in number and, for popular libraries, get a reasonable number of eyes on this type of change.