incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Molinaro <antho...@alumni.caltech.edu>
Subject Re: Cassandra access control
Date Thu, 03 Dec 2009 20:03:11 GMT
I also like this feature, I also use keyspaces as another dimension
for some applications.  I also don't worry about "securing" cassandra
as I run behind firewalls.  I can see the argument for authentication
per keyspace, but I like it as optional.

For instance consider the use case where you have are running a chat
server with public rooms and private rooms.  Public rooms live in a
keyspace with no authentication, and private rooms each have their
own keyspace with a token (a bit contrived, but you get the idea hopefully).

Users would have unauthenticated access to one keyspace and authenticated
access to others but be able to query both over the same connection.

-Anthony

On Wed, Dec 02, 2009 at 04:43:19PM -0500, Jake Luciani wrote:
> I like this bug/feature it gives another dimension to play with.  
> Especially when keyspaces can be defined on the fly. Not a huge  
> restriction though.
> 
> Sent from my iPhone
> 
> On Dec 2, 2009, at 4:22 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> 
> >What backwards compatibility are you concerned with breaking?
> >
> >Having keyspace be a per-command arg is a bug, not a feature.
> >
> >On Wed, Dec 2, 2009 at 2:54 PM, Mark Robson <markxr@gmail.com> wrote:
> >>How about we make authentication optional, and have the protocol  
> >>being
> >>stateful only if you want to authenticate?
> >>
> >>That way we don't break backwards compatibility or introduce extra
> >>complexity for people who don't need it.
> >>
> >>Mark
> >>

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@alumni.caltech.edu>

Mime
View raw message