Archiva
  1. Archiva
  2. MRM-694

Virtual repositories or repository grouping

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1
    • Component/s: repository interface
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      4

      Description

      A number of managed repositories can be grouped together with that group having only one url. So you only need to specify that url in the settings.xml file and when Archiva receives a request via that url, it would look for that artifact from the repositories belonging to that group.

      More details are dicussed here:
      http://www.nabble.com/Archiva-1.1-Roadmap-td15262645.html#a15263879

      1. MRM-694-archiva-configuration.patch
        1.0 kB
        Nap Ramirez
      2. MRM-694-archiva-webapp.patch
        11 kB
        Nap Ramirez
      3. MRM-694-archiva-webdav.patch
        6 kB
        Nap Ramirez
      4. MRM-694-web-interface.patch
        64 kB
        Maria Catherine Tan

        Issue Links

          Activity

          Hide
          Maria Odea Ching added a comment -
          Show
          Maria Odea Ching added a comment - Additional info in: http://www.nabble.com/Virtual-Repositories-td16741542.html
          Hide
          Maria Catherine Tan added a comment -

          Submitted a patch for the web interface part of this issue

          Show
          Maria Catherine Tan added a comment - Submitted a patch for the web interface part of this issue
          Hide
          Nap Ramirez added a comment -

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

          Show
          Nap Ramirez added a comment - patch containing a utility method for getting the repository groups as a Map<String repositoryId, RepositoryGroupConfiguration>
          Hide
          Nap Ramirez added a comment -

          patch for adding the repository groups feature

          Show
          Nap Ramirez added a comment - patch for adding the repository groups feature
          Hide
          Nap Ramirez added a comment -

          patch of unit tests for the repository group feature

          Show
          Nap Ramirez added a comment - patch of unit tests for the repository group feature
          Hide
          Nap Ramirez added a comment - - edited

          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)

          Show
          Nap Ramirez added a comment - - edited 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)
          Hide
          Maria Odea Ching added a comment - - edited

          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.

          Show
          Maria Odea Ching added a comment - - edited 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.
          Hide
          Maria Odea Ching added a comment -

          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.

          Show
          Maria Odea Ching added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

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

          Show
          Maria Odea Ching added a comment - I'm leaving this open while I'm still testing this feature.
          Hide
          Maria Odea Ching added a comment -

          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

          Show
          Maria Odea Ching added a comment - 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
          Show
          Maria Odea Ching added a comment - http://www.nabble.com/Authentication-in-Virtual-Repositories-td17204716.html
          Hide
          Maria Odea Ching added a comment -

          Fix in trunk -r657012:

          • perform authentication only in ArchivaDavSessionProvider.attachSession()
          • perform authn and authz for each repo in ArchivaDavResourceFactory.createResource()
          Show
          Maria Odea Ching added a comment - Fix in trunk -r657012: perform authentication only in ArchivaDavSessionProvider.attachSession() perform authn and authz for each repo in ArchivaDavResourceFactory.createResource()
          Hide
          Maria Odea Ching added a comment -

          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.

          Show
          Maria Odea Ching added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

          Additional fix in trunk -r658525:

          • add authorization check for virtual repos
          Show
          Maria Odea Ching added a comment - Additional fix in trunk -r658525: add authorization check for virtual repos
          Hide
          Maria Odea Ching added a comment -

          Additional fix in trunk -r658528:

          • handle problem with the missing '/' in the repository group url
          Show
          Maria Odea Ching added a comment - Additional fix in trunk -r658528: handle problem with the missing '/' in the repository group url
          Hide
          Brett Porter added a comment -

          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.

          Show
          Brett Porter added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

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

          Show
          Maria Odea Ching added a comment - Ok, I'll adjust the authentication.. thanks for testing this out Brett
          Hide
          Brett Porter added a comment -

          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)
          Show
          Brett Porter added a comment - 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)
          Hide
          Maria Odea Ching added a comment -

          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.

          Show
          Maria Odea Ching added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

          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.

          Show
          Maria Odea Ching added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

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

          Show
          Maria Odea Ching added a comment - Changed return to 405 for write requests to a virtual repo (fixed in trunk -r659071)
          Hide
          Maria Odea Ching added a comment -

          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!

          Show
          Maria Odea Ching added a comment - 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!
          Hide
          Marecor M. Baclay added a comment -

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

          Show
          Marecor M. Baclay added a comment - I tested this feature and found out MRM-818 and MRM-819 .
          Hide
          Maria Odea Ching added a comment -

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

          Show
          Maria Odea Ching added a comment - Okay, I'll take a look at those two issues.. Thanks Marecor!
          Hide
          Brett Porter added a comment -

          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.

          Show
          Brett Porter added a comment - 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.
          Hide
          Maria Odea Ching added a comment -

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

          Show
          Maria Odea Ching added a comment - Brett, I can't seem to replicate this Were you logged in Archiva when you accessed the repo group?
          Hide
          Brett Porter added a comment -

          nope, I wasn't

          Show
          Brett Porter added a comment - nope, I wasn't
          Hide
          Maria Odea Ching added a comment -

          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.

          Show
          Maria Odea Ching added a comment - 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.
          Hide
          Brett Porter added a comment -

          you're right sorry!

          Show
          Brett Porter added a comment - you're right sorry!

            People

            • Assignee:
              Maria Odea Ching
              Reporter:
              Maria Odea Ching
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: