cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Courtney Robinson <sa...@live.co.uk>
Subject Re: PHP Cassandra CQL driver
Date Tue, 29 Mar 2011 14:41:38 GMT
This is the last post on the dev list, moving over to client-dev
Agreed on the reverse eng. of the java driver. Dave has dome some classes/interfaces based
off the python version. He’s going to commit them when he gets a chance.

From: Nick Telford 
Sent: Tuesday, March 29, 2011 12:06 PM
To: dev@cassandra.apache.org ; client-dev@cassandra.apache.org 
Cc: Courtney Robinson 
Subject: Re: PHP Cassandra CQL driver

I have to say I'm not a huge fan of reverse-engineering the interface, especially not from
the Java implementation. I think we'd be better off using the other drivers (in particular,
the python driver) as inspiration and then craft an interface that fits in with PHP. 

With regards to injection, I saw someone state "it's a red herring as it's a client concern".
While this may be true, experience teaches us that pushing the responsibility to the client
is dangerous due to the many implementations. At the very least, the possibility of injection
attacks should be *considered*. 

My suggestion as a means of heavily mitigating the damage of these attacks would be to only
permit a single query at a time (i.e. remove the ';' token). Only trusted, administrative
client applications (e.g. a GUI or console) should really permit issuing multiple queries
like this. Such clients could decompose the queries in to separate queries and issue them
individually.

It might also be helpful for the RPC interface to permit executing a batch of queries (list<string>)
to reduce network overheads.

Finally, we should take this conversation over to the client-dev list, rather than add to
the noise on the dev list.

Regards,

Nick Telford

On 29 March 2011 10:34, Courtney Robinson <sabco@live.co.uk> wrote:

  Okay, Dave Gardner, Nick Telford and myself met at the London Cassandra meetup.
  We were keen on getting a PHP CQL driver done and decided to use github while working on
it.
  This mail is mainly to raise awareness of this as well as to ask a few questions and throw
a few things
  out there that came up.

  These are in no particular order and are just how I remember them.
  Firstly, has it already been taken into consideration that CQL implicitly means injections
may become a problem?

  Secondly and this wasn’t so much of a problem but more of a suggestion. While going through
the Java and Python
  versions, there was a significant lack of docs. I think at the moment that’s because Eric
Evans may be the only one
  moulding CQL together but if we’re going to get many drivers done It will help other Devs
and not scare off potential
  devs. who aren’t close or overly familiar with Cassandra’s internals.

  For Devs interested in contributing to the PHP Cassandra (PHPCad) driver, its on github
@ https://github.com/zcourts/PHPCad

  We also wondered about actually making this an “official” driver. Once it is in a stable
state, do we just let Eric or one of the other committers know or is there a particularly
long winded process that has to be followed?

  The code on Github at the moment is a reversed engineered version of the Java impl. in PHP.
I think we’ve agreed that its too “JDBC” like with a lot of methods etc that aren’t
necessary/needed so Dave has written up some classes and interfaces off the Python version
so we’ll be changing the base code to those as soon as he gets some time.

  I’m sure there were other things, possibly more important that I’ve forgotten since
the meetup but they’ll come to light in due time. Again, the driving force behind this at
the moment seems to need more man power, we’d like to get a bit more momentum behind it
and kick off drivers in a few other languages. Anyone wishing to contrib. should get it out
there.

  For ref, a very good link explaining the CQL syntax posted yesterday I believe
   https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message