Darren New wrote: > Tracy R Reed wrote: >> Darren New wrote: >>> For PHP and MySQL, it's not the wrong way to go. True, you need to >>> throttle your SQL thru the MySqlEscape function, but really, if >>> you're manually concatenating things together to make SQL, you should >>> be making a library or something. >> >> Yes, I will probably recommend the making of a library as well. > > I have one with routines > build_select > takes the name of a table and an array of column->value > build_insert > ibid, except with a parameter that allows for "replace" as well > build_update > takes table name, array of selections, and array of new values, > as well as an optional argument that keeps it from checking that > num_rows (or whatever it's called for updates) returns exactly 1. > > They all quote their arguments appropriately. The routines to perform > the queries are > query($sql, $mnemonic) > and > update($sql, $mnemonic) > Each does the query, returns the result set, and if it fails throws > an error with the indicated $mnemonic in it (which basically is > enough for me to find the right line easily). update() just calls > query() and then makes sure exactly one row got changed. > > Handy especially when you're going direct from form to table row.
Pardon me if I belabor a point here, even at the risk of insulting your intelligence (and/or disclosing my lack thereof) by misinterpreting your remarks, but I think there is a big point to make, that might be important to onlookers. The "direct from form" phrase suggests to me that the example variable above, "$sql" (maybe) comes from form post data. Post data can, of course, be spoofed, so there is no certainty that the data returned with your form's action is the data that was intended by virtue of your own html. It raises an especially big reaction from me since it is a completely unnecessary risk, easy to avoid: => There is no reason to have post data provide anything resembling sql. You can always return a token (eg, "SEARCH_BY_FIRST_NAME"), and then look up the sql from a hash (or something equivalent) The code is arguably more maintainable, to boot. The sql could even be further buried in class member code, or some such, but the big point is that post (or query) data may not be what your form was expected to return -- and you shouldn't assume so. It's obvious that one should be suspicious of user input. It's important to also realize that form data might not be what you expect, and merits similarly strong defenses. ..I guess I'll stop now :-) Regards, ..jim (thanks for humoring me) -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
