Package Manager behaviour varies by instance type (author/publish):
# -----------------------------
# Author
# -----------------------------
$ curl http://localhost:4502/crx/packmgr/service.jsp?cmd=ls -u whatever:blabla -v
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 4502 (#0)
* Server auth using Basic with user 'whatever'
> GET /crx/packmgr/service.jsp?cmd=ls HTTP/1.1
> Host: localhost:4502
> Authorization: Basic d2hhdGV2ZXI6YmxhYmxh
> User-Agent: curl/7.53.1
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Wed, 07 Feb 2018 16:32:14 GMT
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="Sling (Development)"
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
# -----------------------------
# Publish
# -----------------------------
$ curl http://localhost:4503/crx/packmgr/service.jsp?cmd=ls -u whatever:blabla -v
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 4503 (#0)
* Server auth using Basic with user 'whatever'
> GET /crx/packmgr/service.jsp?cmd=ls HTTP/1.1
> Host: localhost:4503
> Authorization: Basic d2hhdGV2ZXI6YmxhYmxh
> User-Agent: curl/7.53.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 07 Feb 2018 16:31:00 GMT
< Content-Type: text/plain; charset=utf8
< Transfer-Encoding: chunked
<
<crx version="1.4.17" user="anonymous" workspace="crx.default">
<request>
<param name="cmd" value="ls"/>
</request>
<response>
<data>
<packages>
</packages>
</data>
<status code="200">ok</status>
</response>
</crx>
* Connection #0 to host localhost left intact
At the moment strange things can happen if AEM credentials are incorrect (i.e. credentials are injected dynamically at runtime and the process didn't work). Here's the use case:
- empty package list gets returned
- Chef assumes that package is not installed
- upload attempt gets triggered
Publish instance handles this in the following way:
$ curl -F package=@/local/path/to/a/package.zip http://localhost:4503/crx/packmgr/service/.json/?cmd=upload -v
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 4503 (#0)
> POST /crx/packmgr/service/.json/?cmd=upload HTTP/1.1
> Host: localhost:4503
> User-Agent: curl/7.53.1
> Accept: */*
> Content-Length: 11721691
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------a761e3934c0c46df
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Wed, 07 Feb 2018 16:44:48 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 50
<
* Connection #0 to host localhost left intact
{"success":false,"msg":"This tree does not exist"}
200 gets back to the user, however {"success":false,"msg":"This tree does not exist"} is present in the response body.
The cookbook validates the response and returns an error, which is correct in this case. However a few extra checks can be made to make user experience better:
- whenever empty package list gets back from AEM or the response contains
user="anonymous" at least some warning should be displayed
- upload/install process should validate response code alongside the body (just the latter is verified at the moment)
Package Manager behaviour varies by instance type (author/publish):
At the moment strange things can happen if AEM credentials are incorrect (i.e. credentials are injected dynamically at runtime and the process didn't work). Here's the use case:
Publish instance handles this in the following way:
200 gets back to the user, however
{"success":false,"msg":"This tree does not exist"}is present in the response body.The cookbook validates the response and returns an error, which is correct in this case. However a few extra checks can be made to make user experience better:
user="anonymous"at least some warning should be displayed