Yeah, that's basically why I wrote EasyDB. https://github.com/paragonie/easydb
$rows = $db->run('SELECT * FROM comments WHERE blogpostid = ? ORDER BY created ASC', $_GET['blogpostid']);
foreach ($rows as $row) {
// etc
}
In a language that already has string interpolation you're telling them to use a crappier custom version of string interpolation that's safe for databases.
Tutorials need to be more upfront about that.
I may be wrong, so please correct me if so.
Over the years, we built one in-house at http://qbix.com/platform/guide/database because we couldn't find one. It does things like sharding out of the box, because it's able to understand the query's criteria and target it to the right shards.
As an interesting side note: Laravel's AR ORM (=Eloquent) is built on top of the Query Builder so you can leverage Query Builder with AR if you know what you're doing. Can also lead to big problems if you don't realize the possibilities and the caveats.
Chicken and egg.
Education is the security strategy that pays forward the most.
There's no technical reason the language couldn't make it so that string literals can be identified at runtime.
There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.
...
The answer is: Data being treated as an instruction.
Solution: Separate them so that data can never be interpreted as an instruction!
In SQLi, this solution is to use parameterized queries. You send the query in one packet, then the parameters in a second one. SQLi is thus prevented.
(Not that SQLi is the only vulnerability possible.)
So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.
Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.
Some wants to learn from bottom up(analytic approach), others want to see cool stuff then tweak, modify, replace to find the limits (holistic approach).
IIRC there is a tendency that young people prefer the holistic approach while teachers either are selected for or grow into preferring the analytical approach.
"Make them suffer like us and they will learn the holy truth" ;D
It's not like you learned to speak with your parents reading you the dictionary beginning with the letter A.
Some do, some don't.
jQuery is a common way to learn to do front end programming. It saves a lot of time when used well. But it is important to extend the knowledge to core javascript and be able to write code when jQuery is not available (like when writing scripts to embed on different sites).
Can you name a few such annoyances and how Laravel addressed them?
And do you mean to say that Laravel addresses them, while other frameworks don't?
It's easier point to framework that's already using PDO and and making sane defaults and solving bootstrapping problems. Once you've learned bunch of new concepts like ORM in one framework, it's easy to understand other ORs and be able to compare it to DMs.
My own experience with Laravel has been really positive. Actually I was thinking about creating something similar until I learned about Laravel, so it solved lots of existing annoyances regarding PHP coding for me.
Everybody needs to start somewhere and I believe that by nudging towards Laravel, my young friend'll learn more in the long run and in the meantime can concentrate on making services instead of writing home grown PDO helpers and custom routing libraries. They are problems that have been solved already multiple times.
Also, Symfony and Laravel communities are encouraging and teaching about the better ways of doing things so that'll help him in the long run.
In many small project it's more fun and more easier to use $favorite_framework instead of searching for reinvented wheel. There are cases when it's better to do more custom solutions but for many cases frameworks are just awesome