incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Cassandra access control
Date Thu, 12 Nov 2009 17:01:58 GMT
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