4 ms·
Disagree. Escaping/sanitizing on output takes extras cycles/energy that can be spared if the same process is done once upon submission. Think more sustainable
by TheChaplain 2y ago
Disagree.
Escaping/sanitizing on output takes extras cycles/energy that can be spared if the same process is done once upon submission.
Think more sustainable.
- oops 2y agoYes I love seeing < in my database. Every time I see it I think oh boy how many cycles will I save when I display this in HTML!
- sameoldtune 2y agoIt’s a trade off for sure. But if you know at the time of collection all the ways in which your data is going to be used in the future, you work at a more well-run organization than me!
- TheChaplain 2y agoObviously one thing does not exclude the other, but the more processed data is before, the less has to be done later for every page retrieval. It surprises me that this seem unfamiliar these days?
- kolinko 2y agoThat is true only for simple systems that don't change often and that have a single view of the data. For most real world use cases your approach is break even at best, and often way worse.
- BoredPositron 2y agoYou mean it's not suitable for the deploy every hour crowd it has nothing to do with complexity.
- vouwfietsman 2y agoNot sure the escaping/sanitizing proposition can hold a candle to the overwhelming performance dumpster fire that is modern web dev.
- carlmr 2y agoI was going to say this sounds like optimizing the stuff that takes 0.1% of runtime for performance over safety. Of course you'd need to measure this for your application, but without a performance measurement maybe it's better to default to security.
- cellardweller 2y agoNo, that's what caches are for.
- kolinko 2y agoDid you calculate that, or are you just guessing?
- viraptor 2y agoWhat do you escape for? Html? Postscript? Json? SQL? Latex? Custom report generator which haven't been created yet but you'll start using in 2 years? Things move - you can't choose the escaping format at input time.
- bruce343434 2y agoSolve problems you have, not ones you invent
- viraptor 2y agoHtml, Json, SQL are the very basics which most web apps will run into. You don't have to invent anything to get more than one possible output format.
- bruce343434 2y agoFor SQL you already have the language provided sanitation of prepared statements. For most backends, the output format is always json, which ends up on the frontend via dedicated browser APIs that don't allow html injection. Maybe if you also directly render some html from the backend, that would change things. Document these assumptions in your central code standards/architecture document to get everyone aligned, and then just stick to it and enjoy a more sane codebase.
- viraptor 2y agoSo what you're proposing is encode to html on input, to sql on output, passthrough to html, and encode to Json on output but after decoding from the saved html - and just document it well?
- deleted 2y ago[deleted]
- bruce343434 2y ago