Integrated portal setting Content-Type as application/json for GET API call

Im facing an issue specific to the integrated portal.

The portal has an API with a GET endpoint. When I use the 'Try this API' feature in the integrated portal to test the API call, I get the following error:

{
	"fault": {
		"faultstring": "Failed to execute the RegularExpressionProtection StepDefinition RE.SecureMessageParameters. Reason: Unexpected token  at position 0.",
		"detail": {
			"errorcode": "steps.regexprotection.ExecutionFailed"
		}
	}
}

The API proxy uses a regex protection policy as below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="RE.SecureMessageParameters">
    <DisplayName>RE.SecureMessageParameters</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <JSONPayload>
        <JSONPath>
            <Pattern ignoreCase="true">[\s]*((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b))</Pattern>
            <Expression>$</Expression>
        </JSONPath>
    </JSONPayload>
    <Source>request</Source>
</RegularExpressionProtection>

This regex protection policy is in a shared flow and I want to keep it generic for all APIs in the organisation. This policy will check all message parameters- headers, query params & payload. But I don't want it to fail if there's no payload for a particular proxy endpoint.

On trace, I noticed that the API call through the integrated portal is setting the request header:

'Content-Type' with value 'application/json'. There is also an empty request body seen during trace.

Note that this Content-Type header & empty body is not set when I call the API using curl/postman. It's only set when called from the portal.

8741-screenshot-at-jun-26-15-50-05.png

8742-screenshot-at-jun-26-15-51-53.png

This is probably why the regex protection policy is forced to check the payload and then it fails when it cannot find it. On the other hand, the policy causes no issues when the API is called through curl command.

The spec looks like the following:

 /retailers:
  get:
    summary: Get Retailers
    description: Retrieves a list of Retailers
    operationId: getRetailers
    tags:
      - guests
    security:
      - apiClientId: []      
    responses:
      '200':
        description: Successful. Retailers list returned
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/retailerData"

Is this a known bug in the integrated portal?

Do I have to put in some workaround to either

- remove the content-type header for GET endpoints

- stop using a shared regex policy with payload check

- update something in the spec

or is there a better solution?

Thanks in advance.

0 1 429
1 REPLY 1

Hi @charvi gahlot

one quick solution for you is to set condition over regex on shared flow which ll stop the execution for the regex of JSON payload like this


<Request>
  <Step>
     <Name>Regex-for-json-payload-check</Name>
  </Step>
  <Condition>(request.verb != "GET")</Condition>
</Request>

you can add more verbs where you don't want to check for the same.

Let me know if you have more queries

Thanks