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

[tinyt6510512]

Dear AEM Community,

I finished to update the dispatcher for allow the proxy clientlibs but it didn't load when the domain is pointing to AEM publisher.

Error  404 in browser

Error in AEM publisher

1. The dispatcher allow rule.

/0029 { /type "allow" /url "/etc.clientlibs/*" }

Maybe I miss come configuration.

Any help would be greatly appreciated.

Thanks,

Thomas.

[Techaspect_Solu]

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/

[tinyt6510512]

Hi,

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

Thanks,

Thomas.

[Techaspect_Solu]

Hi tinyt6510512,

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

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

Thanks,

Techaspect Solutions.

[tinyt6510512]

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.

[Feike_Visser1]

Can you add clientlibs also to the allowed extensions?

[Jörg_Hoh]

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

[steveb87657034]

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

        }

[susheel]

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

[Daniel245]

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​

[brace011]

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

[cqsapientu69896]

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

[cqsapientu69896]

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 ?

[kautuk_sahni]

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

~kautuk

[cqsapientu69896 · Accepted solution]

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.

[huvu]

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.

[harshaperfect]

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.