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

Would have to override that file in /apps

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?

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?

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

Jörg

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

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

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

WHere did you read that?

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.

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