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

SOLVED

AEM postback gives HTTP 204 instead of HTTP 200

rohan_pulekar
Level 1
Level 1

The setup:
I am working on a website hosted in AEM.
There is a Single page app (SPA) on the website for a certain transactional flow.
In this transactional flow SPA there is a payment step where user enters credit card details.
For this payment step I show user an iframe that is hosted by a third party payment processor.
After user enters their credit card and clicks submit, the payment processor does a postback to a success URL on my host website.
The postback is POST ..../reserve.paymentsuccess.html  where reserve is the SPA page and paymentsuccess is a custom AEM selector I have created in my website code as:   apps/cq/Page/paymentsuccess.POST.html
So this POST goes to AEM publisher which gives response HTTP 200 and in response body it gives the html that I have in /apps/cq/Page/paymentsuccess.POST.html .  This html is just:  
<script type="application/javascript"> window.parent.postMessage({type: 'payment-redirect', success: true, paymentSessionId: paymentSessionId}, "*");</script>

this all works fine on prod, on all staging environments, and developers local machine.

 

The issue:
On just one AEM publisher of a particular staging environment, the  POST ..../reserve.paymentsuccess.html   is giving HTTP 204 with no response body.  And since there is no response body window.parent.postMessage mentioned never happens and user gets stuck there.
Any idea why this one staging environment AEM publisher would erroneously give HTTP 204 instead of HTTP 200

1 Accepted Solution
davidjgonzalezz
Correct answer by
Employee
Employee

Hi,

 

Using the AEM Web Console (aka Felix console), use the "Sling Servlet Resolver" tool on the misbehaving AEM Publish node to see what servlet the POST request resolves to:

 

http://localhost:4502/system/console/servletresolver

 

You can compare this a "working" Publish node. The Servlet Resolver can sometimes act a bit wonky, so alternatively, you can make your POST to the end-point in question, and review

 

Recent requests: http://localhost:4502/system/console/requests

 

This will show the FULL trace of of how the request is processed. 

 

If it is resolving to your script properly, then it sounds like there is an issue w/ the script on that Publish node. Review the script, and even try making a benign change to it to force a recompile.

If these tools DONT show the expected script, then it sounds like your script is not deployed correctly; review to make sure it exists in the expected location under /apps.

 

What youre doing should certainly work, but i figure i'd mention my preferred pattern for attaching selectors to cq:Page resources is using a Sling Opting Servlet as shown here: https://github.com/Adobe-Consulting-Services/acs-aem-samples/blob/master/core/src/main/java/com/adob...

Writing Java code in a bonafide Java class is cleaner, more testable, and easier to trace/log/debug (IMO). You can also tie your behavior to specific cq:Page's easily with the Opting check, rather than attaching the POST paymentsuccess to EVERY cq:Page. 

View solution in original post

4 Replies
davidjgonzalezz
Correct answer by
Employee
Employee

Hi,

 

Using the AEM Web Console (aka Felix console), use the "Sling Servlet Resolver" tool on the misbehaving AEM Publish node to see what servlet the POST request resolves to:

 

http://localhost:4502/system/console/servletresolver

 

You can compare this a "working" Publish node. The Servlet Resolver can sometimes act a bit wonky, so alternatively, you can make your POST to the end-point in question, and review

 

Recent requests: http://localhost:4502/system/console/requests

 

This will show the FULL trace of of how the request is processed. 

 

If it is resolving to your script properly, then it sounds like there is an issue w/ the script on that Publish node. Review the script, and even try making a benign change to it to force a recompile.

If these tools DONT show the expected script, then it sounds like your script is not deployed correctly; review to make sure it exists in the expected location under /apps.

 

What youre doing should certainly work, but i figure i'd mention my preferred pattern for attaching selectors to cq:Page resources is using a Sling Opting Servlet as shown here: https://github.com/Adobe-Consulting-Services/acs-aem-samples/blob/master/core/src/main/java/com/adob...

Writing Java code in a bonafide Java class is cleaner, more testable, and easier to trace/log/debug (IMO). You can also tie your behavior to specific cq:Page's easily with the Opting check, rather than attaching the POST paymentsuccess to EVERY cq:Page. 

View solution in original post

rajput-ankur
Level 1
Level 1
I am also facing a similar kind of issue in case of SAML. When the IdP is redirecting to AEM with SAMLResponse, it is returning 204 No Content. But if I execute the same request through Postman then it is working perfectly fine. I couldn't find the request neither in request and access logs nor on Recent requests console: http://localhost:4502/system/console/requests. I even added a breakpoint on SlingMainServlet and the request is not even coming to that,
ottón63171937
Level 1
Level 1

Check Adobe Granite Cross-Origin Resource Sharing Policy OSGi config entries on publishers to make sure that the IdP's origin is an explicitly allowed origin or use .* regexp as allowed origins regexp.

Ankur_Khare
Community Advisor
Community Advisor

Hope the code is same on staging server?

And could please add logs..