Dynamic Media Component - Console Error - 404 - GET /libs/cq/i18n/dict.en-US.json | Community
Skip to main content
Rohan_Garg
Community Advisor
Rohan_GargCommunity Advisor
Community Advisor
November 21, 2022
Solved

Dynamic Media Component - Console Error - 404 - GET /libs/cq/i18n/dict.en-US.json

  • November 21, 2022
  • 1 reply
  • 2258 views

Hi AEM Community,

 

I have the below issue -

We are using a dynamic media component for rendering images and videos.

We are using a proxy to path /libs/dam/components/scene7/dynamicmedia

 

The console in browser is giving the below error -

 

Here are the points which I could follow -

1. The clientlib category of dynamic media has category 'granite.utils' which calls i18n.js file.

 

2. The granite.utils clientlib category at /libs/clientlibs/granite/utils has I18n.js with below code -

 

 

The code fails at the below lines -

xhr.open("GET", HTTP.externalize(getDictionaryUrl(locale)), false); //getDictionaryUrl(locale) returns "/libs/cq/i18n/dict.en.json"
xhr.send(); //Failed to load resource; server responded with status 404

 

This does not happen for author instance but only for publish and dispatcher.

The dispatcher blocked the URL /libs/cq/i18n...

[21/Nov/2022:11:21:42 +0000] [I] [cm-pyyyyy-ezzzzzz-aem-publish-6666cdc68-pw22d] "GET /libs/cq/i18n/dict.en_us.json" -0ms [publishfarm/-] [actionblocked] publish-pyyyyy-ezzzzzz.adobeaemcloud.com

 

We wrote the below filter rules to allow dispatcher to filter this URL -

#Allow i18n dictionary JSON
/0107 { /type "allow" /path "/libs/cq/i18n/*" /extension "json" }

 

Post this the Publish started rendering the i18n URL correctly -

 

 

However, the Dispatcher/Domain Name is still giving 404. On checking the logs here's an interesting observation -

 

When request coming directly to Publish -
21/Nov/2022:13:15:23 +0000 [223] -> GET /libs/cq/i18n/dict.en-US.json?nocache HTTP/1.1 [cm-pyyyyy-ezzzzzz-aem-publish-6d587785c-5nxcc]
21/Nov/2022:13:15:23 +0000 [223] <- 200 application/json 4ms [cm-pyyyyy-ezzzzzz-aem-publish-6d587785c-5nxcc]

 

When request coming from Dispatcher -
18/Nov/2022:13:15:36 +0000 [229] -> GET /libs/cq/i18n/dict.en-US.json HTTP/1.1 [cm-pyyyyy-ezzzzzz-aem-publish-6d587785c-5nxcc]
18/Nov/2022:13:15:36 +0000 [229] <- 404 text/html 7ms [cm-pyyyyy-ezzzzzz-aem-publish-6d587785c-5nxcc]

 

Hence, the request coming directly to publish is being served 200 application/json response type while that coming from Dispatcher is being served with 404 text/html.

 

Can you please help in resolving the console error ? Should there be a change at component level or etc mappings or Dispatcher configuration ?

@arunpatidar, @mohit_kbansal, @b_sravan, @kautuk_sahni, @vijayalakshmi_s, @markusbullaadobe

 

Thanks,

Rohan Garg

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Rohan_Garg

    Hi @rohan_garg!

    You're totally right: it's absolutely not an option to leave the dispatcher without any filtering. Please don't do that! And yes, Cloud Managers quality gates will check the filter setup against best practices and the security check lists to ensure that this does not happen.

     

    The idea of deactivating filters was to verify the assumption that the behavior is caused by the set of filter rules in place. And as written in my initial post: I highly recommend to only do that temporarily (for the cause of verification) and on a lower environment, probably a DEV environment (could even be a local one as the AEM CS SDK comes with a dispatcher).

    If the desired request gets the expected response without any filters, you can start to add your required filter rules one by one (or in batches if your rule set is large), checking again after each addition until the response turns to the unwanted 404. With this method you could work your way towards identifying the rule that causes the issue.

     

    Once you have identified the concerned rule, you can tweak and tune it to allow the desired request while keeping effective filtering for other areas (such as for /apps and /libs) in place.

     

    With regards to the Cloud Manager checks:

    I'm not 100% sure but you might be able to override the validation failure - at least for the DEV environment. For other environments (stage or even production), this would be highly discouraged and I don't recommend to do that. If you're not able to override the validation, even for DEV, you might either:

    • Do the tests on a non-cloud instance, such as a local development environment with dispatcher or
    • start with a non-customized, OOTB filter configuration (or a minimal one that meets the quality gates) instead of an allow all one.

     

    Hope that helps!


    Hi again @markusbullaadobe,

    I was trying to make these changes in DEV environment only not the STAGE or PROD of course.

    Anyways, I was able to find another fix for this problem.

    The OTB Dynamic Media component calls i18n client library

    <sly data-sly-call="${clientLib.all @ categories='cq.dam.components.scene7.dynamicmedia, cq.dam.components.scene7.common.i18n'}" />

     

    Simply overlaying the HTML rendering file and removing the category "cq.dam.components.scene7.common.i18n" helped solve the issue.

     

    Thanks for your help & support!

     

     

     

    1 reply

    MarkusBullaAdobe
    Adobe Employee
    MarkusBullaAdobeAdobe Employee
    Adobe Employee
    November 21, 2022

    Hi @rohan_garg!

    If the request is properly served from the publish instance but returning 404 when requested through dispatcher, this is most likely an issue with the filter rules configured on dispatcher.

     

    This can be verified by e. g. removing all filters (setting to allow all) and double checking if things work as expected. (Disclaimer: Obviously, this should not be done on a production setup but on one of your lower environments.) Once verified, you can fine-tune the dispatcher rules to ensure that the required resources are properly accessible and not filtered. You may want to try different filter configurations/types, such as:

     

     

    { /type "allow" /url "/libs/cq/i18n/dict.*.json" }

     

     

    Another thing to double-check is proper order of the items. Filter rules are interpreted strictly from top to bottom. Please note that the "keys" (such as "/0107") do not influence the order of rule interpretation. So simply changing the key (e. g. from "/0107" to "/0207") will not have any effect on the order of rule interpretation, you need to move the line to the right position of the dispatcher configuration file.

    With that background, please also double check that there are no other definitions interfering with your allow rule. The general recommendation is to first deny everything and then specifically allow the areas that are required for your site/application to work.

     

    You may want to check the documentation on filter definition to see the different possibilities here.

     

    Hope that helps!

      Rohan_Garg
      Community Advisor
      Rohan_GargCommunity AdvisorAuthor
      Community Advisor
      November 21, 2022

      Hi @markusbullaadobe, thanks for your prompt reply ! It's highly appreciated.
      I removed all the filters to see if we get the same results.

      Unfortunately the AEMaaCS build failed when I set allow everything in filters. This is because the Cloud Validator validations failed -

      Cloud manager validator 2.0.44
      2022/11/21 14:49:32 Dispatcher configuration validation failed:
      conf.dispatcher.d/available_farms/brandA.farm: filter allows access to CRXDE
      conf.dispatcher.d/available_farms/brandA.farm: filter allows access to system console

      However, even if it had worked, it would have been a short fix as we usually block all requests for paths such as /apps, /libs as is the general practice.

       

      Ideally when overlaying any component from /libs to /apps we shouldn't need to allow the servlet path in our dispatcher configuration.

      Let me know your views on this!

       

      Thanks,

      Rohan Garg

        MarkusBullaAdobe
        Adobe Employee
        MarkusBullaAdobeAdobe Employee
        Adobe Employee
        November 21, 2022

        Hi @rohan_garg!

        You're totally right: it's absolutely not an option to leave the dispatcher without any filtering. Please don't do that! And yes, Cloud Managers quality gates will check the filter setup against best practices and the security check lists to ensure that this does not happen.

         

        The idea of deactivating filters was to verify the assumption that the behavior is caused by the set of filter rules in place. And as written in my initial post: I highly recommend to only do that temporarily (for the cause of verification) and on a lower environment, probably a DEV environment (could even be a local one as the AEM CS SDK comes with a dispatcher).

        If the desired request gets the expected response without any filters, you can start to add your required filter rules one by one (or in batches if your rule set is large), checking again after each addition until the response turns to the unwanted 404. With this method you could work your way towards identifying the rule that causes the issue.

         

        Once you have identified the concerned rule, you can tweak and tune it to allow the desired request while keeping effective filtering for other areas (such as for /apps and /libs) in place.

         

        With regards to the Cloud Manager checks:

        I'm not 100% sure but you might be able to override the validation failure - at least for the DEV environment. For other environments (stage or even production), this would be highly discouraged and I don't recommend to do that. If you're not able to override the validation, even for DEV, you might either:

        • Do the tests on a non-cloud instance, such as a local development environment with dispatcher or
        • start with a non-customized, OOTB filter configuration (or a minimal one that meets the quality gates) instead of an allow all one.

         

        Hope that helps!

          Terms & ConditionsAccessibility statement

          Loading footer...