Thanks Stu for the information. I have not still looked deeper at the internals of the Cassandra. I just thought the operations such as insert, system_add_column_family, system_add_keyspace in 'Cassandra.Iface' imply an 'add' operation. I just wanted to pass that action to the 'authrorize' method, so that I can give the authority to the user for the resource dynamically prior to do adding. Like a creating a file in the file system - owner gets the read/write authority implicitly. Is it incorrect to decide the 'action' going to be done based on the operations(methods) in 'Cassandra.Iface'? I would glad to know your opinion.
Our intention was that if you wanted to add another permission like "update" (a subset of "write") then you would return it from the method as part of the EnumSet<Permission> for that resource. I would see how much trouble it would be to add a new Permission value for "update".Note that Cassandra itself doesn't make a distinction between "update" and "add", because we don't (and probably can't, without locking?) look for an existing value while doing an insert. This would probably be a larger patch than you think.On Mon, Jan 31, 2011 at 1:54 AM, indika kumara <email@example.com> wrote:Hi All,
Currently, there are two permissions - read and write, and there is no way to know the current operation being performed such as add, update, etc. If the operation is 'add', as the user is already logged into the system, I would like to authorize the user for the resource going to add. I think it is a valid use case, as the creator of a resource implicitly need to have the authority to access it.
public EnumSet<Permission> authorize(AuthenticatedUser user, List<Object> resource);
ission> authorize(AuthenticatedUser user, List<Object> resource, Action action); // Action is a enum and can be 'add', 'update', 'delete', etc.