incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <robin....@bluecoat.com>
Subject RE: Re: Cassandra access control
Date Fri, 13 Nov 2009 00:24:11 GMT
Ted,

Why pass a map of credentials?  Why not follow the standard approach of opening the connection
with the credentials, as in tr.open( uid, passwd )?  For now, that can be an overloaded method
call that would leave the existing API as-is.

Robin.


-----Original Message-----
From: news on behalf of Ted Zlatanov
Sent: Thu 12/11/2009 08:59
To: cassandra-user@incubator.apache.org
Subject:  Re: Cassandra access control
 
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis <jbellis@gmail.com> wrote: 

JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jmischo@quagility.com> wrote:
>> > Let's keep it simple.  Forcing multiple connections from a purely
>> > hypothetical use case is a no-brainer tradeoff.  Connections are not
>> > expensive.

>> Even if we can do it sensibly? Connections aren't hugely expensive, but
>> they're not free, either.

JE> I suppose, but if it requires sending a keyspace param w/ each call,
JE> then it's not sensible.  You waste far more overhead for that in the
JE> common case -- serializing, deserializing, checking that it's been
JE> authed -- than you gain from not having another connection in the
JE> uncommon one.

JE> I would be okay with being able to send a 2nd auth call to an existing
JE> connection to switch the "current" keyspace, similar to how rdbmses
JE> only have one active schema at a time.

How about:

login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException

setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException

and then all the existing API calls won't have a Keyspace parameter as
previously discussed.  This works for everyone, I think, and separates
authentication from authorization nicely.

Ted



Mime
View raw message