cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Mischo <jmis...@quagility.com>
Subject Re: Cassandra access control
Date Thu, 12 Nov 2009 18:32:01 GMT
+1, it's a good solution to both scenarios, with reduced overhead all  
around.

On Nov 12, 2009, at 11:01 AM, Jonathan Ellis wrote:

> works for me.
>
> 2009/11/12 Ted Zlatanov <tzz@lifelogs.com>:
>> 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