Hi All,
The first link below is working correctly but the second link below says Not Found :-
https://author-6.5.2/etc.clientlibs/clientlibs/granite/clientlibrarymanager.js
https://publish-6.5.2/etc.clientlibs/clientlibs/granite/clientlibrarymanager.js
I have checked that allowProxy is true in /libs/clientlibs/granite/clientlibrarymanager on Both servers.
Please can you advise why second link above says Not Found ?
Thank you for your time and advise.
Solved! Go to Solution.
Views
Replies
Total Likes
On the publish server, are you able to reproduce the issue, when you bypass the dispatcher(i.e., access the publish server using its host & port directly)?
a) If not, then enable DEBUG logging for dispatcher, and see which filter is blocking the request. You can then allow this request to go through dispatcher.
b) If it's still reproducible, invalidate cache & rebuild clientlibs via File System, as per [1], clear all browser cache & cookies, close all browser tabs & windows, open a new one in Incognito mode, and then verify whether the issue is still reproducible.
Hope it helps !!
Can you check if the dispatcher is blocking this URL on the publish tier? If that's, not the case, try rebuilding clientlibs to clear the cache.
Hi @James-Collett ,
It will be worth to check the permissions for anonymous users on publishers.
Most of the time 404 issues on publishers are related to permissions for anonymous users.
Try giving read access on /etc, if it is already not there.
@James-Collett Also, does your Dispatcher configuration, https://publish-6.5.2/etc.clientlibs/clientlibs/granite/clientlibrarymanager.js, allow /etc.clientlibs/* ?
Hi @James-Collett,
Please try this solution out on your publish instance:
1. Go to http://hostport/system/console/configMgr
2. Search for and open Apache Sling Authentication Service
3. Add these two entries to the sling.auth.requirements
-/etc.clientlibs
-/etc/clientlibs/granite
4. After changing the property, restart the bundle http://host:port/system/console/bundles/org.apache.sling.auth.core
Thanks!!
On the publish server, are you able to reproduce the issue, when you bypass the dispatcher(i.e., access the publish server using its host & port directly)?
a) If not, then enable DEBUG logging for dispatcher, and see which filter is blocking the request. You can then allow this request to go through dispatcher.
b) If it's still reproducible, invalidate cache & rebuild clientlibs via File System, as per [1], clear all browser cache & cookies, close all browser tabs & windows, open a new one in Incognito mode, and then verify whether the issue is still reproducible.
Hope it helps !!