incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <...@lifelogs.com>
Subject Re: Cassandra access control
Date Thu, 12 Nov 2009 18:09:19 GMT
On Thu, 12 Nov 2009 10:59:52 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> 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.

TZ> How about:

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

TZ> setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException

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

I created an issue:

https://issues.apache.org/jira/browse/CASSANDRA-547

and will post updates there as needed.  This is stage 1, meaning this is
the 0.5 work that will keep the old API.  Stage 2 will remove the
Keyspace parameters from the API so I'll put that work in a different
issue, linked to CASSANDRA-547.

Thanks
Ted


Mime
View raw message