On Wed, May 14, 2008 at 12:55 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > 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 By pretend it's not there meaning send a 'Resource does not exist' error instead of 'Unauthorized' error? > > 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) This is for the browse right? > > > Thoughts? Looks good to me :-) > > - Brett > > Thanks, Deng
