On Wed, May 14, 2008 at 10:52 AM, James William Dumay <[EMAIL PROTECTED]> wrote:
> Deng, > > On Tue, 2008-05-13 at 17:37 +0800, Maria Odea Ching wrote: > > Hi, > > > > I've applied the patches for the virtual repositories (MRM-694), and > we're > > still missing authentication. I was looking at > > how we'll implement the authentication & authorization checks for this > > feature, and stumbled upon a couple of things. > > The setup of our authentication for a resource request (request to a > > specific repo, not group) is as follows: > > > > 1. A client makes a repo request to the RepositoryServlet. > > 2. RepositoryServlet calls ArchivaDavSessionProvider for authentication > & > > authorization checks. > > 3. ArchivaDavSessionProvider returns true if request is allowed and > false if > > not to RepositoryServlet, > > 4. RepositoryServlet then calls ArchivaDavResourceFactory to get the > > resource. > > 5. ArchivaDavResourceFactory looks for the resource in the repo and > returns > > it if found. > > That looks right :) > > > Now, given the implementation of the virtual repositories (or repository > > grouping), the implementation of the authentication > > for the requests needs to be changed. Brett and I discussed two options > for > > this in IRC: > > > > 1. Remove the ArchivaDavSessionProvider and have the authentication & > > authorization checks inside ArchivaDavResourceFactory. But > > we're not sure if the session provider is required or is being used > > elsewhere. > > I'm hesitant to rip this out of Archiva. The session provider is an > integral part of the Jackrabbit WebDAV servlet which allows you to > attach DavSession objects to the request. (These are used for level 2 > locking, among other things). > > > > > 2. Add a dependency to ArchivaConfiguration in ArchivaDavSessionProvider > in > > order to get the repositories if the request was > > for a repo group. Iterate through each of the repositories and do > > authentication & authorization checks. The problem here though is > > that if the user has permission for the first repo and the resource > > requested was actually in the second repo.. then the user > > would still be able to get in. Another thing that we're hesitant to > do is > > having the ArchivaConfiguration in the ArchivaDavSessionProvider. > > It doesn't seem to belong there. > > > > Option #1 is better, but I'm not certain if the > ArchivaDavSessionProvider is > > being used elsewhere or what the impact would be if it is removed. (I > think > > James can answer this :-) > > > > Thoughts? :-) > > > > 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? > I guess this is a cleaner implementation :-) So the changes now will be concentrated in the RepositoryServlet? > > Cheers, > James > Thanks, Deng
