Virtual repositories or repository grouping

Additional info in:
http://www.nabble.com/Virtual-Repositories-td16741542.html

Submitted a patch for the web interface part of this issue

patch containing a utility method for getting the repository groups as a Map<String repositoryId, RepositoryGroupConfiguration>

patch for adding the repository groups feature

patch of unit tests for the repository group feature

The following test cases are handled:

1. Accessing a valid repository group root url (e.g. http://machine.com/repository/repository-group/) returns a Bad Request (HTTP 400)

2. Accessing an invalid repository group root url is forwarded to managed repository checking

3. Accessing an artifact in a valid repository group will iterate over the managed repositories in the repository group
3.a. If an invalid managed repository is encountered (managed repository doesn't exist), a Not Found (HTTP 404) is returned and the iteration is broken

3.b. If an artifact is not found in a valid managed repository (after proxying, etc.), a Not Found (HTTP 404) is set but not returned yet, the iteration continues to the next managed repository. The Not Found (HTTP 404) is returned after exhausting all valid managed repositories

3.c. If an artifact is found in a valid managed repository, the artifact is returned, the iteration is broken and any Not Found (HTTP 404) is disregarded

4. Accessing a valid repository group with any http write method returns a Bad Request (HTTP 400)

Patch MRM-694-web-interface.patch applied in trunk -r655432. Thanks for the patch Marica!

I'm still resolving test failures in archiva-webapp after applying the remaining patches. There have been changes in the webdav module after the patch has been created causing the test failures after I merged them.

MRM-694-archiva-webapp.patch and MRM-694-archiva-webdav.patch applied in trunk -r655749. I made some adjustments in the patch in order to apply it successfully to trunk and for the RepoServlet tests to pass. Thanks for the patches Nap!

I no longer applied MRM-694-archiva-configuration.patch as the same code was also in MRM-694-web-interface.patch already.

I'm leaving this open while I'm still testing this feature.

I encountered some problems regarding authentication:

2008-05-13 15:09:47,487 [btpool0-0] INFO org.apache.maven.archiva.security.ArchivaServletAuthenticator - Authorization Denied [ip=127.0.0.1,isWriteRequest=false,permission=archiva-read-repository,repo=internal.group] : no matching permissions
2008-05-13 15:09:47,487 [btpool0-0] ERROR org.apache.maven.archiva.webdav.ArchivaDavSessionProvider - Access denied for repository internal.group

http://www.nabble.com/Authentication-in-Virtual-Repositories-td17204716.html

Fix in trunk -r657012:

• perform authentication only in ArchivaDavSessionProvider.attachSession()
• perform authn and authz for each repo in ArchivaDavResourceFactory.createResource()

Fix in trunk -r658261:

• handle virtual repos in webdav browse
• add new DavResource for virtual repos

Leaving this issue open until other people aside from me are able to test this further.

Additional fix in trunk -r658528:

• handle problem with the missing '/' in the repository group url

I'm having a problem using them with split authz.

Say the guest has perms to one repo and not the other, I get prompted for auth on the group.

Likewise, if a user has perms to one repo and not the other, their auth fails for the group with:

2008-05-21 14:17:24,210 [btpool0-5] INFO  org.apache.maven.archiva.security.ArchivaServletAuthenticator  - Authorization Denied [ip=0:0:0:0:0:0:0:1%0,
isWriteRequest=false,permission=archiva-read-repository,repo=testing] : no matching permissions

I think that if the current user has access to any repo in the group they are let in, and then what is shown is checked based on their permissions?

But if they have access to none, they are prompted.

Ok, I'll adjust the authentication.. thanks for testing this out Brett

here are some other small adjustments:

• when you deploy, you get 400 BAD REQUEST, but I think maybe 405 on deployment is more appropriate? (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). If not 405, perhaps 403. Reading the spec, both would comply but 400 means we didn't understand the request
• the plain HTML indexes (IndexWriter) are not alphabetically sorted in groups
• in the UI, we should show the group HTTP URL, like the repository URLs we show for each repo
• I was allowed to create group with ID of an existing repository - this should be a conflict
• likewise, I was allowed to create a repository with ID of an existing group - this should be a conflict
• the repository group page HTML seems invalid - probably missing a closing div (see the footer which doesn't extend all the way to the left)

Ok, I'll look into these.. Thanks!
Also, I previously filed an issue before to display the URL of the repo group MRM-802. I'll just link it to this issue.

Fixed authentication problem in trunk, -r659069.

The implementation is that if the current user logged in to Archiva has access to any of the repos in the group the user is allowed to browse with only the artifacts in the repos they have permission to access are shown. But if the user has no permission to access any repository, authentication will be prompted.

Changed return to 405 for write requests to a virtual repo (fixed in trunk -r659071)

Fixed the following in trunk:

• add validation check for existing repo group ids and managed & remote repo ids (-r659443)
• fixed sorting in IndexWriter (-r659397)
• fixed footer in repo groups page (-r659392)

I'm leaving this issue open until the fixes are verified. Thanks!

I tested this feature and found out MRM-818 and MRM-819.

Okay, I'll take a look at those two issues..
Thanks Marecor!

I found that I was able to access the contents of a repository I didn't have access to via a group it was included in.

Setup:

• 'test' repository (guest has read access)
• 'testing' repository (guest has no access)
• 'all-test' group that includes both

Accessing all-test with the group gives access to both repositories, while accessing via testing asks for authentication.

Brett, I can't seem to replicate this
Were you logged in Archiva when you accessed the repo group?

nope, I wasn't

Hmm.. maybe this happened because of the browsing history stored in the browser?

I was able to replicate this when I previously logged in as 'admin' and browsed the repo group, then logged out. When I accessed the repo group, I was still able to browse everything and when I tried accessing the repo which the guest user has read access, I was prompted for authentication. But when I cleared the browsing history and tried the repo group url again, I was only able to see the repositories which guest has read access to.

you're right sorry!