Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 gcdcu-cassandra-user@m.gmane.org designates 80.91.229.12 as permitted sender)
To: cassandra-user@incubator.apache.org
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Cassandra access control
Date: Wed, 02 Dec 2009 08:52:41 -0600
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 42
Message-ID: <87638pl96u.fsf@lifelogs.com>
References: <87eio6p7pb.fsf@lifelogs.com>
	<e06563880911111455gc9f5c10g1863bbacdcead348@mail.gmail.com>
	<20091112001409.GC12953@alumni.caltech.edu>
	<878webssu6.fsf_-_@lifelogs.com>
	<e06563880911120712m75051e0bv9dfec31cb634dd95@mail.gmail.com>
	<87iqdfrba9.fsf@lifelogs.com>
	<e06563880911120806w70becf6eu50efef0efcd72a88@mail.gmail.com>
	<5B7ECCB8-BF96-4EA1-AAB7-B8C27B824FDF@quagility.com>
	<e06563880911120838r6035eac0rd380e62438945744@mail.gmail.com>
	<DC6830C8-E88C-4D2F-B4E2-A63088599D01@quagility.com>
	<e06563880911120849p4deea68dj4cc95bc9531c62d0@mail.gmail.com>
	<87fx8jptkn.fsf@lifelogs.com> <874oozpqcw.fsf@lifelogs.com>
	<87einfr6a8.fsf@lifelogs.com> <1259699027.19220.37.camel@achilles>
	<87fx7ul6id.fsf@lifelogs.com> <1259708330.19220.59.camel@achilles>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
Cancel-Lock: sha1:XwKp5q7h0PTDfJfIOi3JxxWKepY=
Sender: news <news@ger.gmane.org>

On Tue, 01 Dec 2009 16:58:50 -0600 Eric Evans <eevans@rackspace.com> wrote: 

EE> On Tue, 2009-12-01 at 15:38 -0600, Ted Zlatanov wrote:
>> I disagree, why would you want to forbid switching the keyspace?  That's
>> turning off a currently working feature.  Also, connections are not
>> free, especially across WAN links.

EE> Because it makes a mess out of an API that already confuses people. And
EE> again, I posit that this is a corner case, something that very few
EE> people will actually want to do. We should be optimizing for the common
EE> case.

On Tue, 1 Dec 2009 17:13:24 -0600 Jonathan Ellis <jbellis@gmail.com> wrote: 

JE> It's a currently working feature that (a) only exists in the first
JE> place because it was less bad than postponing 0.4 until we could add
JE> something like this auth feature, and (b) is of entirely theoretical
JE> benefit in the sense that nobody who wants to keep it actually has an
JE> app using it, to the best of my knowledge.

JE> Let's correct our error, and only add functionality that we know is
JE> really needed -- and even then, only if the benefit outweighs the
JE> complexity price -- rather than waving our hands and saying "maybe
JE> someone will need it, someday."  That way leads to clutter and bloat.

OK.  So what should the API be?  Just one method, as Robin suggested?

void login( Map<String, String> credentials, String keyspace ) 
 throws AuthenticationException, AuthorizationException

In this model the backend would still have login() and
setKeyspace()/getKeyspace() separately to distinguish between
authentication and authorization but the frontend API would merge them.

This means the keyspace parameter will be removed from all the current
Thrift API calls and application will need to remember what keyspace
they requested.  It will definitely not make 0.5.

Let me know if this is OK and I'll prepare a new patch.

Thanks
Ted