Paul Houle wrote:
I think of ORM as a partial solution to the problems of building
database-backed web apps. People call database applications "CRUD"
apps, short for
I have no idea what ORM is, mainly because I didn't follow the past
threads, but here is my take of the problem you describe.
> This would have been OK if they'd written something like
$first_name=addslashes($_POST["first_name"]);
$last_name=addslashes($_POST["last_name"]);
$organization=addslashes($_POST["organization"]);
Depending on the database used there are better means. In case of mysql
using mysql_real_escape_string is the way better approach as I learned
not too long ago. With addslashes you get the proper escaping, but upon
retrieval you have to take the surplus slashes back out. When storing
something that has slashes in the original information (windows file
paths for example) how is the code supposed to know which slashes to
take out? And all that although a slash won't break your SQL.
But they didn't. Neither do most developers. Now, there are tools
That is because most developers are ignorant, unqualified, or arrogant
or all three in regards to users some very basic level of quality and
security.* I have seen apps where the developer went through the trouble
to take out anything that might be offending to SQL or the rest of the
code rather than to choose proper delimiters and proper escaping.
I often post opinions in a german online newspaper and they use a PHP
script with MySQL. Of course, that script doesn't do any escaping and
blurts out the whole SQL query upon failure. How easy will it be to drop
some tables, add some, modify, add procedures....in short, that script
is open to SQL injection at the first degree.
I recall that I did exactly the same when I started poking around in
MySQL with PHP until I read about SQL injection and that addslashes is
the way to go - until I tried to store file paths in my tables and all
they stopped working upon retrieval. I then opted to go the ignorant and
unqualified route by not escaping file paths and thus not needing to
strip slashes. Until I came across a folder name with a single quote in
it. Then I learned to do it the right way.
The ORM system takes care of quotes and bad data for you.
One of the lessons of professional software QA and hobbyist PHP
development is "All input is evil!". I always distrust everything even
when it comes from a db record that I just wrote a few seconds ago. In
that sense I think it is a bit foolish to just forget about proper
validation and have some system take care of it. That system is also
just a bunch of lines of code. While I do see the benefits of
simplifying db access and with that abstracting the db layer I still
think that anything that comes in and goes out has to be fully verified
to be good data. Don't expect that you get good data and don't expect
that the other system will take care of bad data (from you or someone else).
This concludes today's lesson. Thank you students.
David
*Note: There are very many honorable exceptions and I know of several
who take things like security, quality, and usability into consideration
- after the lack of doing so bit them hard into their behinds.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
