JSONThreatProtection policy returning incorrect fault

Google Cloud Apigee
1

Hi Team,

We are creating our own keys/codes for APIGEE faults that can occur with in policies as we do not want to pass on the fault names as it is to the consumers and want to customize the error response as per the need.

I was checking JSONThreatProtection policy. my policy code is as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JTP">
    <DisplayName>JTP</DisplayName>
    <Properties/>
    <ArrayElementCount>2</ArrayElementCount>
    <ContainerDepth>3</ContainerDepth>
    <ObjectEntryCount>4</ObjectEntryCount>
    <ObjectEntryNameLength>10</ObjectEntryNameLength>
    <Source>request</Source>
    <StringValueLength>20</StringValueLength>
</JSONThreatProtection>

Now if I send a request as follows:

{
	"myproper1":"sdlfks",
	"myproper2":"myvalue",
	"myproper3":"myvalue",
	"myproper4":"myvalue",
	"myproper5":"myvalue"
}

I was expecting fault “ExceededObjectEntryCount” in the response (as per the policy documentation) but the fault generated is “ExecutionFailed”. Please correct me if I am wrong.

Now the problem is if want to customize the error messages based on the fault name I cannot do that because in any case same fault is written (be it be ObjectEntryCount or ObjectEntryNameLength or any other cause).

Another problem is if I want to extract part of the error message then its difficult to identify which variable will hold the error message, is it error.message/ fault.string because this behavior is not consistent across all the policies which make is very difficult to create a generic error handling pattern for policy faults.

This information is not very clear in the documentation. There are many other observations regarding faults and fault name which I have mentioned in other posts as well. I personally feel that the errors/error codes needs improvement in APIGEE. It is one of the very important aspect in API program.

1 Like
2

ok, I understand what you’ve written here, @Vipul Agarwal.

Let me investigate the specific scenario you described here. We can separately talk later about the general point you raised - that the handling of errors and error codes needs improvement.

3

Hi @Vipul Agarwal

Please find attached a working API Proxy bundle that demonstrates how to distinguish between the different fault conditions triggered by the JSON Threat Protection policy.

vipul-json-1.zip

The basic technique is:

  • Catch the ExecutionFailed fault
  • parse out the fault string
  • assign specific responses based on the contents of that string.

The FaultRules section looks like this:

  <FaultRules>

    <FaultRule name='rule1'>
      <Step><Name>EV-FaultString</Name></Step>
      <Step>
        <Name>AM-ExceededObjectEntryCount</Name>
        <Condition>faultString ~~ ".+ Exceeded object entry count.+"</Condition>
      </Step>
      <Step>
        <Name>AM-ExceededArrayElementCount</Name>
        <Condition>faultString ~~ ".+ Exceeded array element count.+"</Condition>
      </Step>
      <Step>
        <Name>AM-ExceededObjectEntryNameLength</Name>
        <Condition>faultString ~~ ".+ Exceeded object entry name length.+"</Condition>
      </Step>
      <Step>
        <Name>AM-ExceededContainerDepth</Name>
        <Condition>faultString ~~ ".+ Exceeded container depth.+"</Condition>
      </Step>

      <Condition>fault.name = "ExecutionFailed"</Condition>
    </FaultRule>

  </FaultRules>

The ExtractVariables policy is like this:

<ExtractVariables name="EV-FaultString">
    <Source>error</Source>
    <JSONPayload>
        <Variable name="faultString" type="string">
            <JSONPath>$.fault.faultstring</JSONPath>
        </Variable>
    </JSONPayload>
</ExtractVariables>

Those double-squigglies are Regex matchers.

I hope this helps.

I agree with you that this seems like more work than ought to be necessary to catch the right error.

Specifically the ExtractVariables policy ideally should not be necessary. At this point I do not know of a better way to get that information. The good news is that the ExtractVariables policy will run very quickly.

2 Likes