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

Hi tinyt6510512,

I think there are no read permissions(/etc/design) for the anonymous user in the publish.

Could you verify the anonymous user permission in the publish server ?

Thanks,

Techaspect Solutions.

Hi tinyt6510512,

I think there are no read permissions(/etc/design) for the anonymous user in the publish.
Could you verify the anonymous user permission in the publish server ?

Thanks,
Techaspect Solutions.
http://www.techaspect.com/

Hi,

Thanks for your supporting but I tried with anonymous user on publisher ( via IP ) it's worked welll

Thanks,

Thomas.

Hi tinyt6510512,

Can you try by adding the below rule in ".any" file

-- { /type "allow" /url "*.js"   }

Thanks,

Techaspect Solutions.

Hi @Techaspect Solutions​,

I added into the dispatcher.any before ( rule 0041)  it's worked well for other js/css under /etc/....

I just faced this issue with proxy clientlib. I added your rule (0030) for checking and restarted dispatcher but it's the same.

( Noted that the rule for JS has been added in 0041 but I added it again on 0030 for checking )

The screenshot about the configuration for more details.

I really appreciate your help,

Thanks,

Thomas.

​

Can you add clientlibs also to the allowed extensions?

Hi,

if you get this exception on the AEM publish, it's a not an issue with the dispatcher at all, the dispatcher forwards the request to AEM correctly. It's rather an issue on your AEM side.

You wrote, that the under some circumstances (hitting the URL directly) the response was ok and the javascript file has been delivered. Can you elaborate on that and the differences between the working and the non-working scenario?

kind regards,
Jörg

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)'

        }

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

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​

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