You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Andreas Probst <an...@gmx.net> on 2002/10/17 13:50:41 UTC
Getting to know VHR's VCR, was Re: using slide client (run.sh) to access slide server a
Hi Jean-Philippe,
at first I'd like to thank you very much for responding.
Please see intermixed.
Andreas
On 17 Oct 2002 at 13:15, Jean-Philippe Courson wrote:
> Hi Andreas,
>
> > Hi Jean-Philippe,
> >
> > you're right, thanks. I didn't make my point clear enough.
> >
> > I base ACL on groups, with a dynamic number of groups. Users can
> > belong to more than one group. There arise two issues:
> >
> > 1. I would have to list all groups who are not allowed, possibly
> > a rather large number.
> >
> > 2. Users, who belong to a blocked group, will be blocked, even
> > if they belong to a group which isn't. At least it should be
> > like that if denied permissions win over granted ones.
>
> You are rigth. Users can only belong to one group per subtree.
>
> > So what I do is:
> >
> > - Set scope (in web.xml) to /files,
> > - give all inheritable permissions on /history for everybody
> > - set ACL entry for a newly created VHR based on the ACL of the
> > VCR or parent of the VCR
> > - browse /history and serve history versions with my own
> > servlets, which check permissions themselves based on the ACL
> > entries of the VHR (no inheritance, not the parents)
>
> You can also avoid to set ACLs on /history and verify permissions
> with your own servlet by verifying VR's associated VCR permissions.
Yes, that's what I thought, too. There arose the problem to find
out the VCR. As I had seen this can not as easily be done as the
other way around, i.e. get to know the VHR of a VCR by reading
DAV:checked-in and DAV:checked-out properties.
Julian Reschke were so nice to point me to the relevant point in
the specs
(http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.4),
which seems rather complicated for me to use within a programme
making use of Slide (Server) API.
But because I'm still interested in a solution to find out VHR's
VCR for another reason I would appreciate hints for this.
Thanks.
Andreas
> Regards
>
> Jp
>
> > I think there will be problems with versioning-aware
> > WebDAV/DeltaV clients. But I think I can live with this. All I
> > need is a basic means of versioning and WebDAV-access only for
> > the current version.
> >
> > Andreas
> >
deleted older messages
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Getting to know VHR's VCR, was Re: using slide client (run.sh) to access slide server a
Posted by Andreas Probst <an...@gmx.net>.
Hi Jean-Philippe,
at first I'd like to thank you very much for your responses. I
really appreciate these, as they give some new ideas and input
to my project. It's a good idea to pass the VCR url instead of
the VHR url. I think I'll change my code as soon as I find the
time to do it.
Bye then.
Andreas
On 17 Oct 2002 at 16:24, Jean-Philippe Courson wrote:
> If you write your own servlet, you can give it VCR path and
> wanted revision as argument rather than VR path.
>
> Having VCR path, is easy to verify permissions.
>
> After, to retrieve corresponding VR, you can read VCR's checked-in
> property, extract from it corresponding VHR and add revision
> to VHR to obtain VR uri.
>
> Does it help ?
>
> Jp
>
> > Hi Jean-Philippe,
> >
> > at first I'd like to thank you very much for responding.
> >
> > Please see intermixed.
> >
> > Andreas
> >
> >
> > On 17 Oct 2002 at 13:15, Jean-Philippe Courson wrote:
> >
> >
> >>Hi Andreas,
> >>
> >>
> >>>Hi Jean-Philippe,
> >>>
> >>>you're right, thanks. I didn't make my point clear enough.
> >>>
> >>>I base ACL on groups, with a dynamic number of groups. Users can
> >>>belong to more than one group. There arise two issues:
> >>>
> >>>1. I would have to list all groups who are not allowed, possibly
> >>>a rather large number.
> >>>
> >>>2. Users, who belong to a blocked group, will be blocked, even
> >>>if they belong to a group which isn't. At least it should be
> >>>like that if denied permissions win over granted ones.
> >>
> >>You are rigth. Users can only belong to one group per subtree.
> >>
> >>
> >>>So what I do is:
> >>>
> >>>- Set scope (in web.xml) to /files,
> >>>- give all inheritable permissions on /history for everybody
> >>>- set ACL entry for a newly created VHR based on the ACL of the
> >>>VCR or parent of the VCR
> >>>- browse /history and serve history versions with my own
> >>>servlets, which check permissions themselves based on the ACL
> >>>entries of the VHR (no inheritance, not the parents)
> >>
> >>You can also avoid to set ACLs on /history and verify permissions
> >>with your own servlet by verifying VR's associated VCR permissions.
> >
> >
> > Yes, that's what I thought, too. There arose the problem to find
> > out the VCR. As I had seen this can not as easily be done as the
> > other way around, i.e. get to know the VHR of a VCR by reading
> > DAV:checked-in and DAV:checked-out properties.
> >
> > Julian Reschke were so nice to point me to the relevant point in
> > the specs
> > (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.4),
> > which seems rather complicated for me to use within a programme
> > making use of Slide (Server) API.
> >
> > But because I'm still interested in a solution to find out VHR's
> > VCR for another reason I would appreciate hints for this.
> >
> > Thanks.
> >
> > Andreas
> >
> >
> >>Regards
> >>
> >>Jp
> >>
> >>
> >>>I think there will be problems with versioning-aware
> >>>WebDAV/DeltaV clients. But I think I can live with this. All I
> >>>need is a basic means of versioning and WebDAV-access only for
> >>>the current version.
> >>>
> >>>Andreas
> >>>
> >>
> >
> > deleted older messages
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Getting to know VHR's VCR, was Re: using slide client (run.sh)
to access slide server a
Posted by Jean-Philippe Courson <ju...@apache.org>.
If you write your own servlet, you can give it VCR path and
wanted revision as argument rather than VR path.
Having VCR path, is easy to verify permissions.
After, to retrieve corresponding VR, you can read VCR's checked-in
property, extract from it corresponding VHR and add revision
to VHR to obtain VR uri.
Does it help ?
Jp
> Hi Jean-Philippe,
>
> at first I'd like to thank you very much for responding.
>
> Please see intermixed.
>
> Andreas
>
>
> On 17 Oct 2002 at 13:15, Jean-Philippe Courson wrote:
>
>
>>Hi Andreas,
>>
>>
>>>Hi Jean-Philippe,
>>>
>>>you're right, thanks. I didn't make my point clear enough.
>>>
>>>I base ACL on groups, with a dynamic number of groups. Users can
>>>belong to more than one group. There arise two issues:
>>>
>>>1. I would have to list all groups who are not allowed, possibly
>>>a rather large number.
>>>
>>>2. Users, who belong to a blocked group, will be blocked, even
>>>if they belong to a group which isn't. At least it should be
>>>like that if denied permissions win over granted ones.
>>
>>You are rigth. Users can only belong to one group per subtree.
>>
>>
>>>So what I do is:
>>>
>>>- Set scope (in web.xml) to /files,
>>>- give all inheritable permissions on /history for everybody
>>>- set ACL entry for a newly created VHR based on the ACL of the
>>>VCR or parent of the VCR
>>>- browse /history and serve history versions with my own
>>>servlets, which check permissions themselves based on the ACL
>>>entries of the VHR (no inheritance, not the parents)
>>
>>You can also avoid to set ACLs on /history and verify permissions
>>with your own servlet by verifying VR's associated VCR permissions.
>
>
> Yes, that's what I thought, too. There arose the problem to find
> out the VCR. As I had seen this can not as easily be done as the
> other way around, i.e. get to know the VHR of a VCR by reading
> DAV:checked-in and DAV:checked-out properties.
>
> Julian Reschke were so nice to point me to the relevant point in
> the specs
> (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.4),
> which seems rather complicated for me to use within a programme
> making use of Slide (Server) API.
>
> But because I'm still interested in a solution to find out VHR's
> VCR for another reason I would appreciate hints for this.
>
> Thanks.
>
> Andreas
>
>
>>Regards
>>
>>Jp
>>
>>
>>>I think there will be problems with versioning-aware
>>>WebDAV/DeltaV clients. But I think I can live with this. All I
>>>need is a basic means of versioning and WebDAV-access only for
>>>the current version.
>>>
>>>Andreas
>>>
>>
>
> deleted older messages
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>