Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

External AEM POST Requests renders Content Modified Response

Avatar

Avatar
Validate 1
Level 1
VKumar20
Level 1

Likes

0 likes

Total Posts

2 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
View profile

Avatar
Validate 1
Level 1
VKumar20
Level 1

Likes

0 likes

Total Posts

2 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
View profile
VKumar20
Level 1

23-02-2021

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
Locationxyz
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)? 

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Ignite 1
Level 4
davidjgonzalezzzz
Level 4

Likes

54 likes

Total Posts

60 posts

Correct Reply

20 solutions
Top badges earned
Ignite 1
Give Back 5
Give Back 3
Give Back 10
Give Back
View profile

Avatar
Ignite 1
Level 4
davidjgonzalezzzz
Level 4

Likes

54 likes

Total Posts

60 posts

Correct Reply

20 solutions
Top badges earned
Ignite 1
Give Back 5
Give Back 3
Give Back 10
Give Back
View profile
davidjgonzalezzzz
Level 4

23-02-2021

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 🙂 .. AEM uses POSTS and especially those handled by the Sling Default POST servlet liberally. Blocking anything that isn't a POST to a very specific URL is asking to break AEM's OOTB functionalities. You should instead, use ACLs to control what content/content trees an AEM Author can write to via the POSTs (which will result in a 403, not a 200 if the user does not have permissions to write to the target path)

 

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.

 

Answers (2)

Answers (2)

Avatar

Avatar
Ignite 1
Level 4
davidjgonzalezzzz
Level 4

Likes

54 likes

Total Posts

60 posts

Correct Reply

20 solutions
Top badges earned
Ignite 1
Give Back 5
Give Back 3
Give Back 10
Give Back
View profile

Avatar
Ignite 1
Level 4
davidjgonzalezzzz
Level 4

Likes

54 likes

Total Posts

60 posts

Correct Reply

20 solutions
Top badges earned
Ignite 1
Give Back 5
Give Back 3
Give Back 10
Give Back
View profile
davidjgonzalezzzz
Level 4

23-02-2021

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).

 

[1] https://github.com/adobe/aem-project-archetype/blob/master/src/main/archetype/dispatcher.ams/src/con...

Avatar

Avatar
Establish
MVP
BrianKasingli
MVP

Likes

583 likes

Total Posts

564 posts

Correct Reply

218 solutions
Top badges earned
Establish
Ignite 1
Give Back 5
Give Back 3
Give Back 10
View profile

Avatar
Establish
MVP
BrianKasingli
MVP

Likes

583 likes

Total Posts

564 posts

Correct Reply

218 solutions
Top badges earned
Establish
Ignite 1
Give Back 5
Give Back 3
Give Back 10
View profile
BrianKasingli
MVP

23-02-2021

@VKumar20,

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
}