When I hit the below url http://localhost:4502/content/geometrixx-outdoors/en.infinity.json, I am getting the following response
["/content/geometrixx-outdoors/en.4.json","/content/geometrixx-outdoors/en.3.json","/content/geometrixx-outdoors/en.2.json","/content/geometrixx-outdoors/en.1.json","/content/geometrixx-outdoors/en.0.json"]
instead of full json response. I want the response like the below url
http://localhost:4502/content/geometrixx/en.infinity.json
Please help me in this, how can I go with this
Solved! Go to Solution.
Thanks. but why it is not showed full details of child pages information instead of showing
["/content/geometrixx-outdoors/en.4.json","/content/geometrixx-outdoors/en.3.json","/content/geometrixx-outdoors/en.2.json","/content/geometrixx-outdoors/en.1.json","/content/geometrixx-outdoors/en.0.json"]
There is no issue here. THis is the expected result based on the URL you specified. I am seeing it too.
See the JSON heading in the AEM Topic:
https://docs.adobe.com/docs/en/crx/2-3/developing/developers_getting_started.html
Thanks. but why it is not showed full details of child pages information instead of showing
["/content/geometrixx-outdoors/en.4.json","/content/geometrixx-outdoors/en.3.json","/content/geometrixx-outdoors/en.2.json","/content/geometrixx-outdoors/en.1.json","/content/geometrixx-outdoors/en.0.json"]
Rama,
Infinity is a special selector handle by defaultSlingServlet. If it works the way you want to, there will be serious consequences. Let's see if someone wants to render all the content (http://localhost:4502/content.infinity.json
Jitendra
Thanks to all. In OSGI configuration, JSON Max results option is available for default sling servlet. With that option we can return maximum number of results.
Hi
Yes, as mentioned, Json max result is use to limit the rendering.When this limit is exceeded the rendering will be collapsed. The default value for Sling within AEM is 200.
Link:- https://docs.adobe.com/docs/en/aem/6-1/administer/security/security-checklist.html
Thanks and Regards
Kautuk Sahni
Thanks @Kautuk.
"APACHE SLING GET SERVLET" config.
Are you getting a "300 Multiple Choices" response code? That's what I get when I see a list of urls like this on a related issue I am having. I am running 6.4.8.1 and still have this issue. If I figure it out, I will let you know.
Views
Replies
Total Likes
It seems that if a page is returning more than 200 resources when using the infinity selector, then the Apache Sling GET Servlet will return the list of paths indicating selectors 0 through 5 instead of the json nodes. This seems to happen on pages that have a lot of content nodes.
You can fix this by setting the "Json Max Results" 200 value to a higher number.
I read somewhere that a lower number here is to protect against DOS attacks by repeat requests to pages with the infinity selector....
Generally I am thinking that our code should not make .infinity calls, otherwise it will be subject to this limit. I am exploring the AEM OOTB code because the cut/paste operation in the TouchUI makes a call to infinity.json and it causes cut/paste to fail if the page has more than 200 resources.
I'll report more when I know it.
/system/console/configMgr/org.apache.sling.servlets.get.DefaultGetServlet
Update Bug Scope Affected Instances
The problem affects all author instances. The LSA Homepage is the page that helped discover this bug, but in actuality, any page in the author instance that has over 200 resources will experience failing cut/paste operations. Cause Debugging in browser shows that a paste operation preceded by a cut operation makes a request to:
which is returning the HTTP Status Code: 300 Multiple Choices.
This is not the desired response. The code making this call is expecting a JSON representation of the page. Here is an example:
The reason this happens is because the Apache Sling DefaultGetServlet has configured a "JSON Max results" value of 200 resources. The LSA homepage has more than 200 resources available to be returned, therefore the servlet detects this and uses the 300 code to inform the client that there are different selectors other than "infinity" that can be used. Interestingly, the copy/paste operation does not use the infinity selector, as shown here: Copy/Paste RUNMODES Shown in the image above are all the places in our project code that reference json.maximumresults Also indicated is that our custom code overrides a value of 1,000 set by Adobe's code in:
This article from Adobe indicates that the default is 200. AEM Explanation for JSON Max Results. It is likely that this article is out of date and that at some point Adobe updated their code to use 1,000. There is a DayCare ticket for this: DayCare Ticket References
Solution
The Apache Sling DefaultGetServlet has configured a "JSON Max results" value of 200. This limit can be increased to a larger number. The following screenshot shows that the AEM Dispatcher is configured specifically for publish instances, but not for author instances, to deny the infinity selector. Examining the code base shows there is not denial of the use of the infinity selector on the author instances. This is because it is needed on author for operations [case in point: cut/paste]. The comment shown in the dispatcher image indicates that the infinity selector is denied in order to prevent DOS attacks. In the same vein of thinking, the Apache Sling DefaultGetServlet has this "JSON Max results" configuration for a similar reason. To help prevent DOS. It is important to keep in mind that this servlet exists on both the author and publisher instances. Therefore it makes sense that a limit option is available. The author instance is protected behind password accounts, therefore if we assume that our authors are responsible, non-malicious users, we can argue that the 200 limit can be increased on the author instance. It is still advisable to use a limit because without it, as the reference article above explains, a .json request on the root of the instance can cause a json dump for the entire repository which would likely degrade overall performance of the instance. It is not known if this would cause a crash or not. | |||||||||||||||
Update
Code Change
Root Cause
Commits The code change setting this number back to 1,000 was essentially unneeded as it would have been just as valid to delete the special runmode overrides. Doing so would have the
configuration take effect.
I reviewed this configuration and it was decided to set this value explicitly in our code rather than utilize the AEM configuration because we are approaching security from the perspective of the security checklist and not from the OOTB configurations. Therefore, by explicitly configuring these limits in our runmodes, we have a committed record that we observed the security checklists, [with notes explaining why we deviated when necessary, as in this case]. |
Views
Replies
Total Likes
Views
Likes
Replies