3 Replies Latest reply on Apr 14, 2013 8:41 PM by Kristian Wright

    This node already exists: /etc/packages

    Kristian Wright Level 1

      Hello all!

       

      I've been trying to upload packages into CQ5 via Java, based on the documented curl commands at http://dev.day.com/docs/en/crx/current/how_to/package_manager.html, but I've hit a strange issue when trying to upload packages to publish instances.  The reason I'm uploading to the publisher directly is because the package only contains ACL nodes, and these do not seem to replicate from author to publisher (from everything that I've read and tried).

       

      I'm using the older /crx/packmgr/service.jsp method in my Java - I know that this is outdated, but it gives me a better debug output of what goes wrong than the /crx/packmgr/service/.json/?cmd=upload method.  I get the same failures with the newer json methos as well.

       

      When I run my code specifying "author", I get the following response, and the package has uploaded successfully:

       

      <crx version="2.3.15" user="admin" workspace="crx.default">

        <request>

          <param name="file" value="author_package.zip"/>

          <param name="name" value="author_packagename"/>

        </request>

        <response>

          <data>

            <package>

              <group></group>

              <name>author_packagename</name>

              <version>0.01</version>

              <downloadName>author_package.zip</downloadName>

              <size>1754056</size>

              <created></created>

              <createdBy>admin</createdBy>

              <lastModified></lastModified>

              <lastModifiedBy>admin</lastModifiedBy>

              <lastUnpacked></lastUnpacked>

              <lastUnpackedBy>null</lastUnpackedBy>

            </package>

          </data>

          <status code="200">ok</status>

        </response>

      </crx>

       

       

      If I run the following curl command, I get the exact same response as my Java, so I'm happy that the Java is correct and working:

       

      curl -u admin:admin -F file=@author_package.zip -F name=author_packagename http://127.0.0.1:4504/crx/packmgr/service.jsp

       

       

       

      If I run my Java code specifying "publisher", I get the following response, and the package does not upload:

       

      <crx version="2.3.15" user="anonymous" workspace="crx.default">

        <request>

          <param name="file" value="publisher_package.zip"/>

          <param name="name" value="publisher_packagename"/>

        </request>

        <response>

          <status code="500">javax.jcr.ItemExistsException: This node already exists: /etc/packages</status>

        </response>

      </crx>

       

       

      Trying the equivelant curl command, I get the following response, and the package has uploaded:

       

      curl -u admin:admin -F file=@publisher_package.zip -F name=publisher_packagename http://127.0.0.1:4505/crx/packmgr/service.jsp

       

      <crx version="2.3.15" user="admin" workspace="crx.default">

        <request>

          <param name="file" value="publisher_package.zip"/>

          <param name="name" value="publisher_packagename"/>

        </request>

        <response>

          <data>

            <package>

              <group></group>

              <name>publisher_packagename</name>

              <version>0.99</version>

              <downloadName>publisher_package.zip</downloadName>

              <size>12890709</size>

              <created></created>

              <createdBy>null</createdBy>

              <lastModified></lastModified>

              <lastModifiedBy>null</lastModifiedBy>

              <lastUnpacked></lastUnpacked>

              <lastUnpackedBy>null</lastUnpackedBy>

            </package>

          </data>

          <status code="200">ok</status>

        </response>

      </crx>

       

       

      If I take away the -u parameter of the successful curl command, I get the following response, which is the same as my "publisher" Java response:

       

      curl -F file=@publisher_package.zip -F name=publisher_packagename http://127.0.0.1:4505/crx/packmgr/service.jsp

       

      <crx version="2.3.15" user="anonymous" workspace="crx.default">

        <request>

          <param name="file" value="publisher_package.zip"/>

          <param name="name" value="publisher_packagename"/>

        </request>

        <response>

          <status code="500">javax.jcr.ItemExistsException: This node already exists: /etc/packages</status>

        </response>

      </crx>

       

      So....

       

      Does anyone know if a publish instance deals with authentication in a different way from an author instance?  The Java code does not change, but the results are different depending on the type of server I'm trying to upload to.  The fact that the Java "publish" upload reports back as being an anonymous user (which I replicated with the last curl call), but uses the same code as the successful (and authorised) "author" upload besides the package details and port, leads me to believe that it's the CQ5 server that is turning this into an anonymous call.

       

      Anyone have any thoughts on what might be happening here, and the best way to solve it?

       

      Cheers,

      K

        • 1. Re: This node already exists: /etc/packages
          Kristian Wright Level 1

          It was suggested to me that the default permissions for the administrators on the publish instances are different to the author instances, and I should allow read access to the /etc/packages node for the admin group.

           

          After looking at the permissions, 'Read' permissions were indeed denied for everyone at /etc/packages.  I updated the Administrators group on the publisher as suggested, but it seems to have had no effect.  The call to upload still returns:

           

          <crx version="2.3.15" user="anonymous" workspace="crx.default">

            <request>

              <param name="file" value="publisher_package.zip"/>

              <param name="name" value="publisher_packagename"/>

            </request>

            <response>

              <status code="500">javax.jcr.ItemExistsException: This node already exists: /etc/packages</status>

            </response>

          </crx>

           

          It still seems to try the upload as user="anonymous", not user="admin".  To test out a theory based on the permissions, I created a new 'anon' group on the publisher, gave them read access to the /etc/packages node, and added the anonymous user to this group. After running the code again, I got the following result:

           

          <crx version="2.3.15" user="anonymous" workspace="crx.default">

            <request>

              <param name="file" value="publisher_package.zip"/>

              <param name="name" value="publisher_packagename"/>

            </request>

            <response>

              <status code="500">javax.jcr.AccessDeniedException: Access denied.</status>

            </response>

          </crx>

           

          This is expected, as the group has no Create permissions.  I'm extremely reluctant to give anonymous users any more permissions in the /etc/packages tree, and I'm not thinking this direction (granting permissions to anonymous users) is a valid solution.

           

          After returning the anonymous user to its original permissions, when I view the request and access logs for the author and publisher calls, I get the following:

           

          author - request.log:
          12/Apr/2013:11:51:14 +1000 [224] -> POST /crx/packmgr/service.jsp HTTP/1.1

          12/Apr/2013:11:51:14 +1000 [224] <- 401 - 1ms

          12/Apr/2013:11:51:14 +1000 [225] -> POST /crx/packmgr/service.jsp HTTP/1.1

          12/Apr/2013:11:51:16 +1000 [225] <- 200 text/plain; charset=utf8 1625ms

           

          author - access.log:

          127.0.0.1 - - 12/Apr/2013:11:51:14 +1000 "POST /crx/packmgr/service.jsp HTTP/1.1" 401 - "-" "Apache-HttpClient/4.2.3 (java 1.5)"

          127.0.0.1 - admin 12/Apr/2013:11:51:14 +1000 "POST /crx/packmgr/service.jsp HTTP/1.1" 200 721 "-" "Apache-HttpClient/4.2.3 (java 1.5)"

           

          publisher - request.log:

          12/Apr/2013:11:51:17 +1000 [347] -> POST /crx/packmgr/service.jsp HTTP/1.1

          12/Apr/2013:11:51:17 +1000 [347] <- 200 text/plain; charset=utf8 23ms

           

          publisher - access.log:

          127.0.0.1 - anonymous 12/Apr/2013:11:51:17 +1000 "POST /crx/packmgr/service.jsp HTTP/1.1" 200 386 "-" "Apache-HttpClient/4.2.3 (java 1.5)"

           

          It seems that the author upload request is unauthorised at first, and then it uses the credentials I set in the request and makes the call as 'admin'.  As for the publisher upload request, it immediately decides that it's an 'anonymous' request, and does not challenge for the authentication.  As mentioned, I'm using the exact same code in my Java to make the author and publisher calls, including the setting and passing of credentials.  Due to a NDA with my client, I cannot post the full Java code I'm using, but I can say that I'm making the requests with the org.apache.http libraries - DefaultHttpClient, HttpPost, UsernamePasswordCredentials etc.

           

          It seems there's something VERY different in the way that the publisher deals with requests as opposed to the author...

           

          K

          • 2. Re: This node already exists: /etc/packages
            Sham HC Level 7

            Hi KWright,

             

            Admin user does not uses acl evaluation & no need to allow access to the /etc/packages.

            Coming to original issue verify

            *  the configuration of the refferer filter in publish instance.

            *  Make sure admin password is correct (Might be you have different password in each instance).

            *  Check if you uplad directly from crx packagemanager it works.

             

            Thanks,

            Sham

            • 3. Re: This node already exists: /etc/packages
              Kristian Wright Level 1

              Thanks Sham HC,

               

              I actually just resolved this issue about 10 minutes ago.  I ended up forcing basic auth being sent via the Apache HTTP BasicScheme class.  Now it always sends the correct credentials with the basic authentication.  So it has been resolved, but it's still a little odd that the author instance challenges for the authentication, while the publisher does not...

               

              Regardless of the reason, by forcing the authentication from the Java side, I've got it working now.

               

              Thanks for your help!

               

              Cheers,

              K