Yeah. We tried that - for MONTHS. Believe me, it was the last thing we
wanted to do. If you have an sway with the pecl folks or James, we'd
LOVE the help. But James hasn't been responding, and as Andrew said,
talking to pecl folks directly hasn't worked either.
Emails sent. I have an active PHP.
On 04/03/2011 01:38 PM, Clint Byrum wrote:
> Excerpts from Monty Taylor's message of Sun Apr 03 09:49:50 -0700 2011:
>> On 04/03/2011 09:17 AM, Clint Byrum wrote:
>>> Excerpts from Olaf van der Spek's message of Sun Apr 03 08:28:50 -0700 2011:
On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings
Excerpts from Monty Taylor's message of Sun Apr 03 09:49:50 -0700 2011:
> On 04/03/2011 09:17 AM, Clint Byrum wrote:
> > Excerpts from Olaf van der Spek's message of Sun Apr 03 08:28:50 -0700 2011:
> >> On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings
> >> wrote:
> It really isn't that hard
On Sun, 2011-04-03 at 18:43 +0200, Olaf van der Spek wrote:
> On Sun, Apr 3, 2011 at 6:17 PM, Clint Byrum wrote:
> > http://pecl.php.net/package/drizzle/
>
> Are you sure? Last release is from 2010.
Correct, it won't compile with current Drizzle. I've tried working with
the PECL guys to get thi
On 04/03/2011 09:17 AM, Clint Byrum wrote:
> Excerpts from Olaf van der Spek's message of Sun Apr 03 08:28:50 -0700 2011:
>> On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings
>> wrote:
It really isn't that hard to solve this.
>>>
>>> No, I'm not saying it is. But what matters is solving it i
On Sun, Apr 3, 2011 at 6:17 PM, Clint Byrum wrote:
> http://pecl.php.net/package/drizzle/
Are you sure? Last release is from 2010.
Andrew said https://launchpad.net/drizzle-php-ext
--
Olaf
___
Mailing list: https://launchpad.net/~drizzle-discuss
Po
On Sun, Apr 3, 2011 at 6:12 PM, Andrew Hutchings wrote:
> It is at https://launchpad.net/drizzle-php-ext
https://bugs.launchpad.net/drizzle-php-ext/+bug/749471
--
Olaf
___
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-di
Excerpts from Olaf van der Spek's message of Sun Apr 03 08:28:50 -0700 2011:
> On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings
> wrote:
> >> It really isn't that hard to solve this.
> >
> > No, I'm not saying it is. But what matters is solving it in the right way
> > for drizzle, PHP and the co
On Sun, 2011-04-03 at 17:28 +0200, Olaf van der Spek wrote:
> On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings
> wrote:
> >> It really isn't that hard to solve this.
> >
> > No, I'm not saying it is. But what matters is solving it in the right way
> > for drizzle, PHP and the community.
> >
> >>
On Fri, Apr 1, 2011 at 7:45 PM, Andrew Hutchings wrote:
>> It really isn't that hard to solve this.
>
> No, I'm not saying it is. But what matters is solving it in the right way
> for drizzle, PHP and the community.
>
>> Who's responsible for the Drizzle PHP connector?
>
> At the moment, me. (we
On 01/04/11 18:38, Olaf van der Spek wrote:
On Wed, Mar 30, 2011 at 11:08 AM, Andrew Hutchings
wrote:
There are several other things we can possibly do here though, such as:
1. By default multi-statements (ie. more than one SQL statement in a single
query) is disabled in libdrizzle and I thin
On Wed, Mar 30, 2011 at 11:08 AM, Andrew Hutchings
wrote:
> I'm guessing what Olaf is proposing is basically every '?' replacement goes
> through drizzle_escape_string() before being appended to the query. In
> theory this is fine but I'd want to extensively test it, especially with
> varbinary/b
On Wed, 30 Mar 2011 11:39:45 -0500, Brian Moon wrote:
> I think getting HandlerSocket, or something like it in the drizzle
> interface would be great.
While I probably wouldn't oppose a merge of HandlerSocket itself, I
don't think it's the best way to do a NoSQL interface to Drizzle.
I think th
On Tue, 29 Mar 2011 17:43:54 +0200, Olaf van der Spek
wrote:
> Does Drizzle support prepared statements at all?
We do not currently support server side prepared statements.
We removed the MySQL prepared statements code as it moved server memory
management from the server to the client. Just abo
set @my_query='SELECT * FROM t1 WHERE a=@var';
set @var=2;
execute @my_query;
The trick, IMO, is to do all that in one trip to the server. That is one
of the problems with prepared statements now. Single use statements
require to trips to the server.
Brian.
On Wed, 2011-03-30 at 11:39 -0500, Brian Moon wrote:
> > 3. Make the PHP module use the SELECT EXECUTE() syntax with user vars
> > for prepared statements. I'm not sure if you can inject using that, will
> > have to play, if you can it shouldn't be too hard to make a safer
> > version of it.
>
> I
On the pro side for quoting int types it would stop the 1=1 type
injections. But at the same time these could be filtered out on the PHP
side if we know the column needs to be an int.
I actually rely on that syntax for finding bugs during dev. If I end up
with a 1= in my query, I get an error a
If it really does, using %d and %s instead of ? solves that problem.
Actually, that is how our internal escaping system works. It uses
mysqli_real_escape_string plus sprintf. So, I would be +1 for supporting
a sprintf style. That would be the best of both worlds.
Brian.
On 30/03/11 08:34, Olaf van der Spek wrote:
On Wed, Mar 30, 2011 at 5:58 AM, Brian Moon wrote:
Why does it need to know any type? The only important type is the expected
type. The actual variable type is not important as it is not always
indicative of the data within in PHP.
That's what I'm a
On Wed, Mar 30, 2011 at 5:58 AM, Brian Moon wrote:
> Why does it need to know any type? The only important type is the expected
> type. The actual variable type is not important as it is not always
> indicative of the data within in PHP.
That's what I'm asking you. IMO it doesn't need to know any
Why does it need to know any type? The only important type is the
expected type. The actual variable type is not important as it is not
always indicative of the data within in PHP.
Brian.
http://brian.moonspot.net
On 3/29/11 5:25 PM, Olaf van der Spek wrote:
On Tue, Mar 29, 2011 at 11:51 PM,
On Tue, Mar 29, 2011 at 11:51 PM, Brian Moon wrote:
>> PHP knows the type of vars passed.
>
> But, it needs to know the data type in the table. That is why
Why does it need to know this?
--
Olaf
___
Mailing list: https://launchpad.net/~drizzle-discu
since drizzle_query is already established and I think intended to be
similar to the MySQL functionality for minimal changes during
conversion. I'm personally not sure in the 3 seconds of thought I have
given it how to implement correctly it without the client side knowing
the data type. But fee
On Tue, Mar 29, 2011 at 11:25 PM, Brian Moon wrote:
> As a PHP developer, may I say I think this is an oversimplification of the
> issue. The reality is that you can't stop people from writing bad SQL. Also,
No, but you can ensure the simple case is safe.
> there are times when more than just a
As a PHP developer, may I say I think this is an oversimplification of
the issue. The reality is that you can't stop people from writing bad
SQL. Also, there are times when more than just a where clause has to be
built dynamically. So, you end up writing your own user space code to
deal with th
On Tue, Mar 29, 2011 at 7:29 PM, Andrew Hutchings
wrote:
>> The syntax is similar, but there's no reason to use (or wait on)
>> prepared statements to solve this safety issue.
>
> I would probably rather this as a separate PHP function personally,
The function name is not the important point.
>
On Tue, 2011-03-29 at 19:20 +0200, Olaf van der Spek wrote:
> On Tue, Mar 29, 2011 at 7:15 PM, Andrew Hutchings
> wrote:
> >> With by design I mean that the 'Hello Drizzle' example should use the
> >> safe API. The safe case should be simpler than the unsafe case,
> >> instead of the other way aro
On Tue, Mar 29, 2011 at 7:15 PM, Andrew Hutchings
wrote:
>> Does Drizzle support prepared statements at all?
>
> No, as I say there is a blueprint for it in libdrizzle, I guess the
As you said libdrizzle, I assumed it was already in drizzle itself.
>> With by design I mean that the 'Hello Drizzl
Hi Olaf,
On Tue, 2011-03-29 at 17:43 +0200, Olaf van der Spek wrote:
> On Tue, Mar 29, 2011 at 5:09 PM, Andrew Hutchings
> wrote:
> > using the prepared statement API in mysqli would probably be a
> > better/safer option. Having a native prepared statement API in the
> > drizzle plugin would be
On Tue, Mar 29, 2011 at 5:09 PM, Andrew Hutchings
wrote:
> In what way unsafe? If you mean vulnerable to an SQL injection, then
I do
> using the prepared statement API in mysqli would probably be a
> better/safer option. Having a native prepared statement API in the
> drizzle plugin would be g
Hi Olaf,
On Tue, 2011-03-29 at 16:11 +0200, Olaf van der Spek wrote:
> mysql_query() is unsafe (by default/design) and drizzle_query()
> appears to be as bad.
> For whatever reason PHP devs did not want to fix mysql_query(), but
> IMO we should ensure drizzle_query() is safe.
>
> Are there any pl
Hi,
mysql_query() is unsafe (by default/design) and drizzle_query()
appears to be as bad.
For whatever reason PHP devs did not want to fix mysql_query(), but
IMO we should ensure drizzle_query() is safe.
Are there any plans to achieve this?
--
Olaf
_
32 matches
Mail list logo
