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.
Solved! Go to 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.
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,
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/
Views
Replies
Total Likes
Hi,
Thanks for your supporting but I tried with anonymous user on publisher ( via IP ) it's worked welll
Thanks,
Thomas.
Views
Replies
Total Likes
Hi tinyt6510512,
Can you try by adding the below rule in ".any" file
-- { /type "allow" /url "*.js" }
Thanks,
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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
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
Views
Replies
Total Likes
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 ?
Views
Replies
Total Likes
I would request you to create a new question to keep the track of your problem.
~kautuk
Views
Replies
Total Likes
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.
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies