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,
Solved! Go to Solution.
Views
Replies
Total Likes
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
Would have to override that file in /apps
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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
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?
Views
Replies
Total Likes
Why do you want to move this servlet to a different URL?
Jörg
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
"I believe call such as /libs/cq/i18n/dict.en-us.json not consider to be secure one"
WHere did you read that?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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:
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
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Like
Replies