On 12/21/07, Mathieu Bouchard <matju@artengine.ca> wrote:
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.
Well, as I have said, I have not used the placeholder stuff much, and a friend of mine who is one of the lead programmers for a credit bureau here in Chicago says that his company doesn't really use them all that often.
> 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.
Actually, I still don't seem to understand the rules for quoting things, as it appears that every database does it differently. SQLite uses double quotes for somethings, and single quotes for others, and then you got MySQL which seems to quote things differently.
>From this link, you will notices that almost every database seems to do things A LITTLE differently.
As it stands right now, I am leaving the quoting up to the user who constructs the SQL.
> 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).
My comment here was in creating the SQL statement. I was hoping not to create a version of SQL that was specific to PD, that is what I meant by a waste of time.
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.
And then you add to this the differences between different databases. While I hope to be able to swap one database for another, I don't know if it would be possible to do that without having to tweak the SQL statements that were created.
> 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.
Well, this is one of those reasons why I am starting with using SQLite, I think it would be much easier than working with a networked database. And if someone is being 'dishonest', then they are only effecting themselves.
> 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.
Well, if we are allowing these people to construct their own SQL and they are building their own stuff, just how can we stop them from being malicious? I mean, the only real way to stop this completely, is to not produce a network version of this, and only deal with standalone.
Mike