did not want to be quibbling ;)
Anyway, I understand what you describe there seems to be a critical problem for anyone using JDBC stores. What can be done?
Why does it work with other stores, when no order can be defined in SecurityStore? Are the ACEs in the right order when they are added?
Would it be a solution if we had this interface:
public interface SecurityStore extends Service {
List getPermissions(Uri uri); // list of NodePermission
void addPermission(Uri uri, NodePermission permission); // append
void addPermission(Uri uri, NodePermission permission, int index);
void removePermisson(Uri uri, int index);
void removePermisson(Uri uri); // remove all
}or even simpler:
public interface SecurityStore extends Service {
List getPermissions(Uri uri);
void setPermissions(Uri uri, List permissions);
}Oliver
Michael Smith wrote:
Oliver Zeigermann wrote:
Well, your advice has not been ignored completely as it seems. In
http://marc.theaimsgroup.com/?l=slide-dev&m=103637094431479&w=2
Eckehard Hermann pointed that there now is a switch to use the old acl semantics. Maybe this can help. Even though this might imply reorganizing all existing ACL entries (I am no expert at this, I just interpret what is in the thread given above).
Oliver
Right. And, as the last message in that thread discusses, this just leaves the default case broken, and the non-default case is stuck using the old (and drastically less useful) ACL semantics.
In the case where this distinction is neccesary (i.e. when the behaviour of the new and old SecurityImpl differs), the old (and now optional) ACL semantics are not capable of specifying the same access controls as the new one.
This is why I suggested that the SecurityStore interface needed modifying (and the jdbc stores along with it), rather than just reverting to the old/less useful SecurityImpl.
So yes - you're technically correct in that my original message wasn't completely ignored - but the 'solution' ignored my major problem with the patch, and left slide broken by default (at least with any of the jdbc stores).
Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
