Hi James,
it used to be there, at least two years ago or so.
You asked for a pointer, here it is:
$Header:
/home/cvspublic/jakarta-slide/src/webdav/server/org/apache/slide/webdav/WebdavServlet.java,v
1.63 2004/08/05 14:43:34 dflorey Exp $
public void init():
if (directoryBrowsing) {
directoryIndexGenerator =
new DirectoryIndexGenerator
(token, (WebdavServletConfig)getServletConfig());
}
$Header:
/home/cvspublic/jakarta-slide/src/webdav/server/org/apache/slide/webdav/util/DirectoryIndexGenerator.java,v
1.8 2004/08/05 14:43:31 dflorey Exp $
public void generate(HttpServletRequest req, HttpServletResponse res)
while (resources.hasMoreElements()) {
String currentResource = (String) resources.nextElement();
NodeRevisionDescriptor currentDescriptor = null;
permissionsList = null;
locksList = null;
try {
NodeRevisionDescriptors revisionDescriptors =
content.retrieve(slideToken, currentResource);
// Retrieve latest revision descriptor
currentDescriptor =
content.retrieve(slideToken, revisionDescriptors);
} catch (SlideException e) {
> I think here should be a continue for Security exception
// Silent exception : Objects without any revision are
// considered collections, and do not have any attributes
// Any security based exception will be trapped here
// Any locking based exception will be trapped here
}
Regarding the all this traversal stuff: When I worked with this
I would have needed
the possibility to say in a parent: This permission is
inheritable. Then in
some deeper child stop inheritence from parents from here on.
The traverse permission from Warwick Burrows sounds pretty good
though.
However, I think the traverse permission is not how the read
permission works on
collections.
Regards,
Andreas
On 16 Aug 2004 at 14:27, James Mason wrote:
> Awesome. I'll look into a way to fix this. We want to keep the behavior
> it has now (generates a pretty html display) but need to change how it
> gets its list of child resource.
>
> -James
>
> Andrey Shulinsky wrote:
>
> > Aha, you're absolutely right! I've completely forgotten about this
> > GET/PROPFIND difference.
> > About the code - WebdavServlet relies on its parent - HttpServlet - handle
> > GET request if it applies to a collection:
> >
> > if ((methodName.equalsIgnoreCase("GET") ||
> > methodName.equalsIgnoreCase("POST")) &&
> > isCollection(req)) {
> > // let the standard doGet() / doPost() methods handle
> > // GET/POST requests on collections (to display a directory
> > // index pag or something similar)
> > super.service(req, resp);
> > }
> >
> > So this "collection" case should have some special handling. Probably just
> > the substitution of the GET request by the PROPFIND will do the trick but I
> > can't tell for sure - I'm not an expert in their syntax.
> >
> > Yours sincerely,
> > Andrey.
> >
> >
> >>-----Original Message-----
> >>From: Slide Users Mailing List [mailto:[EMAIL PROTECTED]
> >>Sent: Monday, August 16, 2004 4:25 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: Why need read privilege on upstream folders to
> >>achieve a writ e permission
> >>Importance: Low
> >>
> >>I would expect any WebDAV client to behave this way,
> >>actually. A WebDAV client uses PROPFIND to get a list of the
> >>children of a collection. A normal browser on the other hand
> >>issues a GET. The problem here is the GET request is listing
> >>all children rather than just the children the user has
> >>access to. I consider this a security issue, albeit a minor one.
> >>
> >>I'm having trouble tracking down how GETs are handled
> >>specially for collections, so I'm hoping someone who's
> >>familiar with the code will step in with a solution or at
> >>least a pointer in the right direction.
> >>
> >>-James
> >>
> >>Andrey Shulinsky wrote:
> >>
> >>
> >>>Actually, it's not a big deal, although ideally all WebDAV clients
> >>>should work in the same way. I wish I had more time to help in
> >>>testing... For
> >>
> >>now I
> >>
> >>>can say that MacOS WebDAV support is consistent with WebFolders in
> >>
> >>handling
> >>
> >>>GET requests.
> >>>
> >>>Yours sincerely,
> >>>Andrey.
> >>>
> >>>
> >>>
> >>>>You're right. It looks like this is a bug in the way GET
> >>
> >>requests for
> >>
> >>>>collections are handled. I'll look into this.
> >>>>
> >>>>-James
> >>>>
> >>>>Andrey Shulinsky wrote:
> >>>>
> >>>>
> >>>>>Hi, Warwick, James, everybody!
> >>>>>
> >>>>>My 2 cents about the matter.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Just to clarify, your "traverse" permission *is* how the read
> >>>>>>permission works on collections. If you get a list of the
> >>>>
> >>>>children of
> >>>>
> >>>>
> >>>>>>a collection you will only see the children to which you
> >>
> >>have read
> >>
> >>>>>>access as well.
> >>>>>
> >>>>>
> >>>>>It depends on the client, actually. WebFolders are OK, but IE, for
> >>>>
> >>>>example,
> >>>>
> >>>>
> >>>>>shows all children - with 2.0, at least.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>
> >>>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]
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
