On 14/05/2008, at 1:31 PM, Brett Porter wrote:
On 14/05/2008, at 12:52 PM, James William Dumay wrote:
As discussed on IRC, we could probably forward the request to the
appropriate managed repository.
That would work a little like this:
1) Request on a virtual artifact is made
- /repository/myvirtual/artifact/artifact/1.0/artifact-1.0.pom
2) The resource factory looks this artifact up in the repositories
mapped by the virtual.
3) If it has been found, we forward it to the appropriate dav
repository
(/repository/mymanaged/artifact/artifact/1.0/artifact-1.0.pom)
The advantage is that we use the existing repository security for
fetching artifacts from the virtual repository.
Does this look ok?
It looks ok to me. I'm not 100% sure if the step in (3) will work,
but if not surely the request can be embedded inside the existing
request in some way.
These are the additional use cases I think we need tests for:
- index writer directory listing when not all repositories have read
access should only list available items (same for webdav listing)
- should be unable to write to a group / webdav share for a group
should be readonly
I took a closer look - and I think the flow can be adjusted.
Here is what I understand the flow to be at present:
1) attach session
1a) check authn
1b) check repository permission
2) create resource
2a) proxy resource if necessary
3) check precondition (returns true)
4) execute DAV request
The precondition is the bit that is meant to do the authz - but we do
it earlier to prevent proxying something they might not even have
access to.
If we were to have resource level authz, or as we go to add groups, we
don't know up front the authz rules.
How about:
1) attach session
1a) just add credentials we have to the request, don't require
authn or authz
2) create resource
2a) proxy resource if necessary. Require authn if we haven't to
this point. if the user has permission to both read the repo and proxy
the resource (when we later add MRM-579). If no permission, pretend
it's not there
3) check precondition
3a) check for read (or write) access to the resource. Require authn
if we haven't to this point.
4) execute DAV request
This does mean we are checking the read permission twice, but it
should be cached. This also lays some ground work for resource based
permissions later.
Now, as we add the repository groups - this is really a read only-view
that sits on top of the whole thing:
- for a non-collection request, this gets added to the resource
factory as it is now
- for a collection request, we actually need a whole new DavResource
derivative that can handle the virtualised nature of it (and check
security on each resource it attempts to list)
Thoughts?
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
