[wp-hackers] Making WP more secure the evolutionary way

[Chris Williams]

What's the larger objective here?  Coding for some data access language
other than SQL or making WP more secure by using less raw SQL (as the tread
title suggests)?  It seems that in the former case it's an academic
exercise, since SQL is by far the dominant data access language and no one
has demonstrated a need to go elsewhere.  And in the latter, isn't it
protecting against a threat that exists largely in the laboratory?

In either case it seems like a terribly large amount of work (and change,
read: destabilization) mostly based on theory.  And if it makes coding for
WP (core, plugin, theme, whatever) even marginally more complex, it seems to
be moving in the wrong direction.

Just MHO.
Chris


> From: Florian Thiel <flo.thiel+wphackers at googlemail.com>
> Reply-To: <wp-hackers at lists.automattic.com>
> Date: Tue, 27 Jan 2009 11:44:07 +0100
> To: <wp-hackers at lists.automattic.com>
> Subject: Re: [wp-hackers] Making WP more secure the evolutionary way
> 
> On Tue, Jan 27, 2009 at 8:14 AM, Otto <otto at ottodestruct.com> wrote:
>> On Mon, Jan 26, 2009 at 8:45 PM, Mike Schinkel
>> <mikeschinkel at newclarity.net> wrote:
>>> P.S. If you advocates persist in moving in this direction, please do us a
>>> favor and at least write an query client that can understand it's syntax and
>>> allow a user to query MySQL interactively directly from your code.
>> 
>> That's the beauty of overloading. Remember that Zend DB stuff I was
>> talking about before? Using that, you can just as easily query with
>> SQL directly. $db->fetchAll('select whatever') works just as well
>> there too. The API functionality is meant to add to the base, not take
>> away from it. Sometimes it's better to build a query dynamically, in
>> parts. Sometimes, it's not.
> 
> I think Zend or CakePHP are a bit out of reach for WordPress right now
> because it would need some fundamental changes to the code. Zend and
> CakePHP heavily use objects and a data model, which is not explicit in
> WordPress.
> 
> I think there are two ways to go about it which don't straitjacket the
> developers and provide a reasonable set of advantages:
> 
> 1) just package the raw SQL queries in function calls like this:
> 
> $wp_db->select($columns,$conditions)
> e.g.
> $wp_db->select(array('column1','column2'),array('id' => $someid))
> 
> This is already being used for insert and update. Moving all the
> INSERTs, UPDATEs and the simple cases of SELECT, DELETE etc. to the
> abstraction layer already rids us of 200 uses of raw SQL. And it's
> really not much work. (these are the 'method_exists' and
> 'trivial_implementation' cases). For the rest, we could see where we
> would go from there. If it works out well for the simple cases, we
> might also consider the ones that actually need some code to be
> written...
> 
> Matt, Jacob is this something you would approve?
> 
> I'll send proof-of-concept patches for this types later today...
> 
> 2) Create "intentional" abstractions (This is an idea that goes much
> further and moves SQL out of the picture completely; I see that there
> are people that won't like this approach; it's just an idea).
> 
> The basic point of these abstractions is that the caller just says
> what he wants and does not really care how the callee gets the job
> done.
> 
> $wp_db->getPosts()
> $wp_db->getCommentsForPost($id)
> $wp_db->getPostsByTag($tag)
> 
> The problem with this approach is that there could be too many
> functions needed because you would need one for every particular type
> of query. You could unify some query types using keyword arguments
> (like adding 'limit' => 10) but that could hurt readability.
> 
> Florian
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers