Closed narhzih closed 9 months ago
Hi @narhzih can you please mention if there is any specific requirement for which the order of keys is important ?
This might be helpful here: https://stackoverflow.com/questions/9909066/how-to-maintain-the-order-of-a-jsonobject
@sumitsum it has more to do that you can expect exactly what you send. I use AWS Signature V4 and for this, you need to hash the body. I use the localstorage of Appsmith to have the values be exactly the same. When I calculate the signature to send with in my headers, I use this local storage. In my body, I use the local storage as well.
When calculating the signature, the payload needs to match exactly what the HTTP client sends out. This is because the payload is being hashed to SHA256. If the order of the keys is different, this will mean that the payload is different thus the hash will be different.
But, for this particular use case, there is already a merge request open to add AWS Signature V4 as an auth type to Appsmith.
@RickVerkuijlen thanks for sharing info.
Another BE user reported this issue.
What is the status of this issue?
This issue has been closed for several weeks now and also merged in the release branch. But none of the past releases indicate if this issue has been resolved. What is the status of this?
I've reopened the issue because this issue only fixed first order trees. i.e.
{"d" : 1, "c":2 , "b" : 3, "a" : 4 }
was preserved and would appear as -> {"d" : 1, "c":2 , "b" : 3, "a" : 4 }
.
however second order trees i.e. {"b" : {"z" : 1, "x": 2 , "y" : 3}, "a" : 2}
gets ordered {"b" : {"x": 2 , "y" : 3, "z" : 1}, "a" : 2}
this pattern is also true for nth order trees where n > 1.
Working on a holistic fix
Can the initial fix, which only solves top level order, be deployed so that we can at least use AppSmith for these kind of requests?
Furthermore, I appreciate AppSmith putting in the effort, but what took almost four weeks for this issue to be reopened? We have been let to believe it was solved and would be released shortly, but 4 months after our initial comment, it is still an issue.
@Peterkrol12 the top level fix is already deployed
@sondermanish - Just checked, seems this is indeed the case. Customer support could not give me this answer and we could not find this issue mentioned in a changelog.
Thanks for the partial fix, we are looking forward to see the remaining work
@Peterkrol12 @RickVerkuijlen I understand how frustrating it can be to face delays in resolving an issue, and I truly appreciate your patience during this time. As you have seen that the partial fix has been implemented to alleviate some of the immediate concerns. However, achieving a complete resolution is going to take a bit more time, particularly with the year-end holidays approaching.
These times can often slow down processes, but please rest assured that your issue remains a priority for us. We are committed to delivering a full resolution as soon as possible. In the meantime, if there's anything specific that I can assist you with or any additional support you need, please don't hesitate to let me know. Your understanding and patience are greatly valued, and we're here to support you every step of the way.
Is there an existing issue for this?
Description
When making a request to an API, appsmith re-arranges the order of the request body. Here's the API body -
When I sent this through Appsmith, my API got it as - { ConfirmedFields: [ { Value: [Object], Id: 13 } ] } When I sent it through post man, my API got it as - { ConfirmedFields: [ { Id: 13, Value: [Object] } ] }
It seems appsmith re-arranges the order of the fields in the request body.
Steps To Reproduce
Public Sample App
No response
Environment
Production
Issue video log
No response
Version
Cloud & Self - Hosted > 1.9.7