Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

How to prevent call /libs/cq/i18n/dict.en-us.json to download I18N

Avatar

Level 5

Hi,

In our project, to download i18n key/messages there is call of /libs/cq/i18n/dict.en-us.json. Now I want to use /apps/cq/i18n/dict.en-us.json . How can I achieve this.

Thanks,

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

This "/libs/cq/i18n/dict" does only determine the path to which this servlet is bound. It does not describe the location where the i18n translations are stored (although the path of the servlet and the JCR path might be identical).

Internally the translations are looked up via "request.getResourceBundle()", which is Sling code. You might want to check out the code at https://github.com/apache/sling-org-apache-sling-engine/blob/39c35bc3022dc15c8903dc41db525f161f2b9b4... and see what it is doing.

Jörg

View solution in original post

10 Replies

Avatar

Level 10

Would have to override that file in /apps

Avatar

Level 5

I have overlayed this structure already. But if we check over the OOTB servlet which returns the I18N keys in json. it is something like as below.

package com.adobe.granite.i18n.impl;

@Component

@Service({Servlet.class})

@Properties({@Property(

    name = "service.description",

    value = {"ResourceBundle Renderer Servlet"}

), @Property(

    name = "sling.servlet.paths",

    value = {"/libs/cq/i18n/dict"}

)})

public class ResourceBundleExportServlet extends SlingSafeMethodsServlet {

So shall i need to update OOTB functionality and create a servlet same like this?

Avatar

Correct answer by
Employee Advisor

This "/libs/cq/i18n/dict" does only determine the path to which this servlet is bound. It does not describe the location where the i18n translations are stored (although the path of the servlet and the JCR path might be identical).

Internally the translations are looked up via "request.getResourceBundle()", which is Sling code. You might want to check out the code at https://github.com/apache/sling-org-apache-sling-engine/blob/39c35bc3022dc15c8903dc41db525f161f2b9b4... and see what it is doing.

Jörg

Avatar

Level 5

MY translations are getting pick from right location say /apps. Only change i want to bind the servlet /etc or /apps. As this is no mean because its just binding with some name. But if I want to alter this, how can i do?

Avatar

Employee Advisor

Why do you want to move this servlet to a different URL?

Jörg

Avatar

Level 5

I believe call such as  /libs/cq/i18n/dict.en-us.json not consider to be secure one. Please correct me If i am wrong?

Thanks

Avatar

Employee Advisor

Why do you think that requests to such a path is less secure than a request to /apps/cq/i18n/dict.en-us.json?  I don't think that this is the case. In both cases ACL restrictions are applied; plus on publish this URL should never the reached directly (as blocked by dispatcher, see the security checklist).

What you are trying to do is to reconfigure product features; technically that's probably doable, but also some other parts might rely on this path to function properly. You should not do that unless you are told explicitly by Adobe support.

regards,

Jörg

Avatar

Level 10

"I believe call such as  /libs/cq/i18n/dict.en-us.json not consider to be secure one"

WHere did you read that?

Avatar

Level 2

In principle there is no security difference between /apps or /libs, apart from the fact that it may be slightly less error prone to block /libs completely in the dispatcher config.

The default on a publisher instance is that the data is stored in /apps but exposed via the servlet in /libs, but at the same time the /libs folder poses a security risk because it has a lot of URLs that should not be reachable on a publisher.

Thus in earlier AEM versions the recommendation was to block /libs completely, this is no longer the case, see: The Dispatcher Security Checklist

Another side aspect is caching and flushing. For performance reasons i18n strings should be cached in dispatcher (e.g. in the libs folder) but depending on how they are used in the site, editors may want to change and activate them which will require some kind of invalidation.

Avatar

Employee Advisor

On the referenced page I see this statement:

To safely enable full functionality on the publish instances, configure filters to prevent access to the following nodes:

  • /etc/
  • /libs/

This means, that you should block these requests on publish, but on author you cannot lock down that whole path. I would agree on the fact that the list is a bit confusing, because it should clearly separate between author and publish.

Jörg