unfortunately i need a very quick solution for that problem. is there a possibility to order the permissions in the security layer? i dont't know exactly if that would help but i think it could fit my needs if first the positive and then the negative permission are evaluated...
Am Don, 2003-08-14 um 10.59 schrieb Oliver Zeigermann:
> Hi Michael,
>
> 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]
>
>
>
--
Marc Sommer I::Dev
+49 721 91374-364 Schlund + Partner AG
PGP Key-ID: 0743ED19 http://www.schlund.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
