Hello Everyone,
Apologies, the same query has been raised sometime back but having some additional queries. if anyone could give any insights, it would be really helpful.
Request:
POST / HTTP/1.1
Host: www.xyz.com (changed)
Transfer-Encoding: chunked
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Length: 4
Content-Type: application/json
0
Response: Content modified /content/xyz
Status | 200 |
Message | OK |
Location | xyz |
Parent Location | /cotent/xyz |
Path | /content/xyz |
Referer | |
ChangeLog | <pre></pre> |
Modified Resource
Parent of Modified Resource
The above post request(from any third part client like postman etc.) does not modify any thing on AEM however it gives the directory information and a view that something has been modified.
Due to some requirements we can not block the post requests at dispatcher level as well as through referrer filters in AEM.
Apart from filtering and identifying the POST requests at dispatcher level (allow or deny), Is there any other way to handle it? (it should not show 200 with content modified message)
Also if we can modify the default response of such post requests (i believe it is through default SlingPostServlet)?
Solved! Go to Solution.
Views
Replies
Total Likes
Are you attempting to block POST's on AEM Author or AEM Publish?
If you are trying to block POST's on AEM Author, don't
If you are trying to block POST's on AEM Publish. The pattern to do this at AEM Dispatcher is:
1. Deny everything
2. Allow only POSTs for the specific paths/path-patterns you know are required for your application
3. Ensure that your content on AEM Publish is properly protected by ACLs, so any POSTs you DO allow ensure the right ppl are modifying the content.
If you are properly filtering out (DENY'ing) these POST requests at Dispatcher, you will not get a 200, but rather a 404.
If you are referring to a Sling Servlet from AEM, You would probably need to review the business logic. Amend the doPost() method to check for necessary acceptable values. If acceptable values are not matched, you can return your own custom status, for example, 406 NOT ACCEPTABLE.
I am actually assuming that your doPost method returns a "XXX" (whatever your servlet is setting as the response status) status as the response, on every request.
Example Code to Implement 406 HTTP Response:
@Override
protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
if (request.getParameter("test") == null) {
response.setStatus(org.eclipse.jetty.http.HttpStatus.NOT_ACCEPTABLE_406);
}
// your logic
}
Are you attempting to block POST's on AEM Author or AEM Publish?
If you are trying to block POST's on AEM Author, don't
If you are trying to block POST's on AEM Publish. The pattern to do this at AEM Dispatcher is:
1. Deny everything
2. Allow only POSTs for the specific paths/path-patterns you know are required for your application
3. Ensure that your content on AEM Publish is properly protected by ACLs, so any POSTs you DO allow ensure the right ppl are modifying the content.
If you are properly filtering out (DENY'ing) these POST requests at Dispatcher, you will not get a 200, but rather a 404.
I'm also facing this content modified response for my post request when hit from external source. On blocking the post method for the content node in the dispatcher filter, I get a 404 for the page if the page is not cached. However, if the page is already cached and then when a post call to the same page is made, I receive a 200 with content from cache being served inspite the dispatcher filter rejecting the post request. Can someone help on this.
Views
Replies
Total Likes
The best practice to secure AEM Publish endpoints via Dispatcher is to:
1. First Deny EVERYTHING
2. Then Allow only what you need to
This is why the first rule in the OOTB AEM Publish Dispatcher is "DENY *" [1]
In terms of identifying what URL end-points need to be ALLOWED in Dispatcher for POST'ing depends on your application's design. Hopefully custom POST end-points are bound to servlets registered to Servlets by Resource Type and Selector/Extension, and the resource that has the respective sling:resourceType's are permissioned accordingly.
If you actually use SlingPostServlet in your application on AEM Publish, then you would want to ensure that POST requests without any selectors, etc. are ONLY available on the content trees that should be written to using the SlingPostServlet, and those resources are permissions properly so only expected users can write to them.
Generally speaking, I would be concerned if any user that isn't admin has write access to /content (not sure if your original example was just an example).
Views
Likes
Replies
Views
Likes
Replies