AndyP wrote: ↑Sat Mar 04, 2023 11:06 am
mwieder wrote: ↑Sat Mar 04, 2023 3:23 am
...but please don't implement it this way, as it leaves your database wide open to SQLInjection attacks.
Yes agree, this was just an example to get Peter started.
I struggle with these choices myself, whether to provide simple examples or thorough examples.
Many of the examples I post here don't include adequate error checking. It adds more to the code, and to the untrained eye may make a simple concept seem more onerous than it is.
Over time I've gradually been leaning toward accuracy over simplicity, if only because it's a better reflection of how LC is used in real-world contexts.
With security, this choice is both more and less simple.
It's a simpler choice because explaining the "why" behind secure practice is a lot of work, for the reader as well as the writer. Omit it and everything becomes invitingly easy.
But it's also not so simple, as it fills the indexable web with examples unsuitable for actual work, the sort of thing newcomers are most likely to find and use.
With both error checking and security, yeah, they eat up time. But they're also part of the art of programming.
I remember when I was starting out how annoying it was to do all the extra typing to handle errors well. But I've found it doesn't take long before thinking in terms of error handing becomes second nature. Habits will emerge only with practice, and practice will begin only with guidance.
Security is murkier because the scope of threats is beyond what can be known. We have to assume components we depend on will eventually have flaws, and the the bad guys are smarter than us. This can be paralyzingly dismaying, but in the end we have to reach a Zen comfort with at least addressing well-known risks, with the focus being not so much to create the world's first impenetrable system, but just one that would survive review should a question arise about whether we even tried.
It's one thing to be the first site where an exotic zero day was used, but quite another to have a run-of-the-mill exploit we anticipated but just never got around to preventing.
This is good enough for my needs, this is only used for a family shopping list.
Beyond login-password pairs, it's rarely the data they're after. No one cares about my calendar entry for a client meeting.
But the server itself is valuable as a compute resource rentable in a botnet.
Spam, crypto mining, and DDoS are just a few of the things other people's servers are useful for.
One of the biggest DDoSes ever was accomplished by harnessing security cams, since each unit is a tiny computer with an OS and network connection, and with a sloppy firmware update mechanism that was all that's needed to repurpose it:
https://www.techradar.com/news/internet ... er-1329480
Not everyone has time or interest in subscribing to infodec newsletters and reading CVE DBs. But I believe we can raise the bar at least high enough to knock out the script kiddies by encouraging contemporary good practice like sanitizing inputs, staying current with updates, and being mindful of permissions.
It's not the single-user single-machine world many of us started in with HyperCard. Our modern connected world is vastly more interesting, opening up so many more possibilities for using computers to enhance our work and play.
But like they say, with great power comes great responsibility. And like error checking, security awareness is a good habit to establish early on.