AEM 6.3 Proxy ClientLibs didn't work via dispatcher to publisher.

hello,

I solved by adding the mapping -

sling:match etc[.]clientlibs/(.+)

sling:internalRedirect /etc.clientlibs/$1

so that it matches only one character - '.' after /etc

Now both /etc/clientlibs and /etc.clientlibs requests return a response

This above solution is working for me in lower environments.In prod we have multiple domains, can you please let me know if there is a way we could add it as a single regex and gets picked up for all domains?

thank you.

Thanks brace011​,

It works for both AEM 6.3, 6.4 with your solution.

P/S: We need to add these rule in an order. It should be bellow

/0064 { /type "deny" /glob "* /etc*" }

Reproduce with

--------------------

AEM 6.3, 6.4

Site content: http://aem-publish.local/content/we-retail/us/en/men.html

OS: MacOS (v10.13.3)

Apache: 2.4

Dispatcher: dispatcher-apache2.4-darwin-x86-64-4.2.2

Dispatcher setup: Adobe Experience Manager Help | Set up AEM Dispatcher on macOS

Browsers: Chrome, Safari

---------------------

Thanks @cqsapientu69896437 , It doesn't work for me with your solution.

I would request you to create a new question to keep the track of your problem.

~kautuk

Ok, so the issue was with sling mappings, the mappings were appending /content/sitename in front of /etc.clientlibs

Have added a sling mapping for /etc.clientlibs , but now the normal clientlibs path - /etc/clientlibs

does not work because resource resolver converts every /etc/clientlibs  request to /etc.clientlibs

which leads to an error from clientproxy servlet.

/etc/clientlibs/foundation/jquery.min.d7c42e4a257b8b9fe38d1c53dd20d01a.js resolves to Resource=NonExistingResource, path=/etc.clientlibs/foundation/jquery.min.d7c42e4a257b8b9fe38d1c53dd20d01a.js

How can both the paths /etc/clientlibs   , and /etc.clientlibs work through sling mappings ?

Hi Daniel245​ ,

I am getting the same issue , the /etc.clientlibs/ libraries work when accessed on port :4503 on publish instance, but when the request is through dispatcher on port 80, there is a 404 error response and the error in publish logs is -

com.adobe.granite.ui.clientlibs.impl.ClientLibraryProxyServlet Proxy request to /etc.clientlibs/clientlibs/granite/jquery.min.js not supported.

Could you please let me know how was your issue solved, hoping for a positive reply.

Thanks

We had the same issues.  As Jörg Hoh mentioned, this is coming from the Publisher, not the Dispatcher.  The strange part to us was that it behaved differently when hitting the Publisher directly vs through the Dispatcher (via IP) vs through a LB (via DNS).  I'm not quite sure why this was yet.

Both of these requests are from the access.log on the Publisher (and both going through the Dispatcher, one via direct IP to the Dispatcher one via DNS to a LB in front of the Dispatcher)

172.99.99.10 - anonymous 25/Aug/2017:18:08:28 -0400 "GET /etc.clientlibs/clientlibs/granite/coralui3.css HTTP/1.1" 404 - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0"

172.99.99.10 - anonymous 25/Aug/2017:17:56:52 -0400 "GET /etc.clientlibs/clientlibs/granite/coralui3.css HTTP/1.1" 200 111330 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0"

The 200 worked as expected and served the CSS file, the 404 also showed the 'proxy' error in the error.log on the Publisher:

25.08.2017 17:25:19.017 *INFO* [172.99.99.10 [1503696319015] GET /etc.clientlibs/clientlibs/granite/coralui3.css HTTP/1.1] com.adobe.granite.ui.clientlibs.impl.ClientLibraryProxyServlet Proxy request to /etc.clientlibs/clientlibs/granite/coralui3.css not supported.

I am still baffled as to why it worked going to the Publisher directly (and we confirmed we weren't logged in), worked hitting the Dispatcher directly via IP, but didn't work via the DNS/LB.  Both requests on the Publisher end show 'anonymous' as the user.

The FIX, however is this, granting 'anonymous' READ access to the /etc node.  The "etc.clientlibs" you see is actually a "clientlibs" selector on the /etc node!  Without READ permission on /etc the anon user cannot make this request.  However I feel this isn't a well thought out solution (and/or poorly documented) from Adobe as granting READ permissions on /etc comes with it's own security issues such as the ability to see the workflow models under /etc/workflow/models.  It might be cumbersome to apply READ to /etc and then lock down all the children (besides clientlibs and designs).  We attempted to plug some of the holes with restrictions on our Dispatcher end as access to the Publisher is only allowed while on the VPN anyways.

These rules were put in place, specifically the addition of the 'deny' for /etc*:

# Deny etc

/0064 { /type "deny" /glob "* /etc*" }

/0094 { /type "allow" /glob "* *etc/tags/*.infinity.json*" }

#New etc.clientlibs paths

/0095 { /type "allow" /glob "* /etc.clientlibs/clientlibs/* *" }

/0065 { /type "allow" /glob "* /etc/designs/*" }

/0066 { /type "allow" /glob "* /etc/clientlibs/*" }

/0071 { /type "allow" /glob "* /etc/segmentation.segment.js" }

Disregard the numbering order (this doesn't really matter anyways, the only requirement is that they are UNIQUE).  These rules were plucked from other parts of our .any config and put at the bottom of the filters section.

After the READ was enabled on /etc and the dispatcher.any was updated to plug security holes it seems these requests now work via the DNS/LB requests.

I hope this helps!

Cheers,

Bryce

I'm getting the same errors as OP on Publisher - hitting publish URL directly...

Anything with etc.clientlibs is throwing a 404 on the browser and AEM is generating the same ClientLibraryProxyServlet "not supported"

It seems to happen when adding a URL mapping in the Apache Sling Resource Resolver Factory...

The idea being to remove /content/my-site from the URL. I've setup a URL Mapping like so : /content/my-site/:/

This seems to work, however, everything in /etc/clientlibs seems to append /content/my-site base on what the Resource Resolver configuration test returns. To fix this I added /etc/:/etc/ as part of the URL mappings, this fixed the calls but not the /etc.clientlibs/

Any ideas? Am I doing this wrong?

feike_visser​

Seems like the urls which were failing had .clientlibs, so dispatcher was unable to identify the extension.

It looks like Feike's entry helped me.

      # Enable extensions in non-public content directories, using a regular expression

      /0041

        {

        /type "allow"

        /extension '(css|gif|ico|js|png|swf|jpe?g|clientlibs|woff|woff2|tff|swf|svg|eot)'

        }