My version is Release 9.0.0_ZEXTRAS_20221203.RHEL7_64_20221216110457 RHEL7_64 FOSS edition.
Our IT notifies me that users are sending lots of requests where the content-type header (XML) doesn't match the body (JSON) sent to Zimbra.
To be more specific
Such mismatches will be blocked by a WAF, and our IT refuses to whitelist them.
Their proposed solutions include changing request body to an XML or changing the content-type header as JSON.
So I'm looking for a way to achieve one of the solutions.
Our IT notifies me that users are sending lots of requests where the content-type header (XML) doesn't match the body (JSON) sent to Zimbra.
To be more specific
- The request was sent to "https://192.168.1.1/service/soap/NoOpRequest"
This case is also found at
https://192.168.1.1/service/soap/AutoCompleteRequest
https://192.168.1.1/service/soap/SaveDraftRequest
and other similar SOAP pages. (192.168.1.1 is the IP of our Zimbra server.)
- Content-type in the request header was
Code:
application/soap+xml; charset=utf-8
- Sample request body
Code:
{ "Header": { "context": { "_jsns": "urn:zimbra", "userAgent": { "name": "ZimbraWebClient - FF122 (Win)", "version": "9.0.0_ZEXTRAS_20221203" }, "session": { "_content": 122, "id": 122 }, "notify": { "seq": 2 }, "account": { "_content": "user1@demo.com", "by": "name" }, "csrfToken": "0_a2f2f......" } }, "Body": { "NoOpRequest": { "_jsns": "urn:zimbraMail" } }}
- This issue is seen only in the request header, and content-type in the response header seems to be correct.
Such mismatches will be blocked by a WAF, and our IT refuses to whitelist them.
Their proposed solutions include changing request body to an XML or changing the content-type header as JSON.
So I'm looking for a way to achieve one of the solutions.
Statistics: Posted by dibery — Wed Feb 21, 2024 5:51 am