On Thu, 13 Dec 2007, Mike McGonagle wrote:
As someone who has never really used Placeholders, the only sorts of things that I can see them being useful for are when you need to do a lot of inserts or deletes, or for other statements that will be executed repeatedly. From what I am gathering by these discussions is that the useage of placeholders allows the SQL statement to be "compiled" and then with each execution of the statement, the values of the placeholders are substituted.
You seem to think of placeholders as something extra that you necessarily add for improving the speed because inserting text within SQL seems perfectly normal. This is not the case. From another perspective, everything that can be abstracted out ought to be abstracted out, and that means that you don't want to touch SQL syntax with your data, you want to think of a SQL statement as a function that you call in your main programming language, you don't want to have to do type conversions and quoting because that's an aspect of SQL and not of your main programming language.
This might be one reason you don't see them all that often in PHP, I would imagine that PHP doesn't really do a whole bunch of repetitive stuff.
So far, all successful attacks on my server has been through PHP scripts that don't quote things properly. For example, embedding text directly into email headers without regard for email syntax.
This idea of doing this to make this more PD-like I think would be a waste of time, as SQL is pretty simple and a LOT of people already know it. Why create another "language"?
Because that other language would be more integrated with pd itself and integration is good, if it really makes things feel more familiar. You can witness the importance of this by looking at how much people avoid using other programming languages with pd (beyond the difficulties in compiling externals and distributing patches that use code like that).
The big downside of integration is that it usually does not cover the whole feature set of what is being wrapped, and especially not nonstandard extensions.
At the same time, should our external be on the look out for these sorts of things? One of the original ideas was to not give the external any, if at all, knowledge of SQL. Meaning, it wouldn't "parse" the SQL, nor would it try to do any generation of SQL. It just expects that the user is HONEST (that is what these concerns over Injection are, right), and the SQL they entered is what they meant.
You can't assume that the user is honest, because when you do, you also assume that the user does not make mistakes when including input from other sources that can't be assumed to be honest.
While we can try to protect against various things, those that want to be malicious will do so anyway.
This is not true. Every step is important in making it more difficult for abuse to happen.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada