r2 - 05 Apr 2005 - 17:20:23 - BrianMoseleyYou are here: OSAF >  Journal Web  >  ContributorNotes > BrianMoseleyNotes > BrianMoseley20050404

Chandler/Cosmo Interoperability Testing (cont.)

Test 4: Version Storage Access Control

Enhanced the Cosmo AccessManager? to allow read access to version storage for all users. This is not a secure solution, but it's all that i can do given the current Jackrabbit internal APIs. The issue has been raised with the Jackrabbit folks, and they are kicking around ideas about how to solve the problem. I've mitigated exposure by using web layer security to deny servlet requests for /jcr:system and below.

Once again attempted to test my WebDAV account and got the following:

  • PROPFIND /webdav/bcm/ returns 207
  • PROPFIND /webdav/bcm/27cde8ac-a572-11d9-cf8a-000d935d33e8.tmp returns 404
  • PUT /webdav/bcm/27cde8ac-a572-11d9-cf8a-000d935d33e8.tmp returns 201
  • DELETE /webdav/bcm/27cde8ac-a572-11d9-cf8a-000d935d33e8.tmp returns 403

The problem here is that jackrabbit, while deleting the resource, checks to see if the user has permission to read the root resource (/). Unless the user is in the root role, he is not granted this permission. So, the DELETE fails.

Note: Chandler does not seem to notice the 403 error and happily reports that I have both read and write access to the account.

Test 5: Root Node Access Control

As a workaround, enhanced the Cosmo AccessManager? to provide read access to the root node for all users and used web layer security to deny access to the root node for all but root users. Emailed the jackrabbit list to find a long term solution.

Once again attempted to test my WebDAV account and got the following:

  • PROPFIND /webdav/bcm/ returns 207
  • PROPFIND /webdav/bcm/1b84bbd6-a575-11d9-cf8a-000d935d33e8.tmp returns 404
  • PUT /webdav/bcm/1b84bbd6-a575-11d9-cf8a-000d935d33e8.tmp returns 201
  • DELETE /webdav/bcm/1b84bbd6-a575-11d9-cf8a-000d935d33e8.tmp returns 403

Now jackrabbit reports an internal exception which suggests that i'm using its API incorrectly to determine access control for a deleted item. More investigation required.

Chandler still seems happy to ignore the DELETE's 403.

-- BrianMoseley - 04 Apr 2005

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.