Handling Regex Faults

Not applicable

I am getting an error in Regex protection policy when the request is not correct.

I want to customize the error thrown.

For this,I am using Raise fault next to Regex policy and giving condition as below,

<Step> <Name>ApiCommonComponent_RaiseFault_BadData</Name> <Condition>fault.name = "regularexpressionprotection.failed"</Condition> </Step>

But,this fault check is not executed when I verify in trace.

As I see that "regularexpressionprotection.failed" flow variable is set as true when error occurs at regex,

I even tried condition as ,regularexpressionprotection.failed == "TRUE" .But even this is not working.

I am not seeing any variable named fault.name while the error is thrown.

The complete error detail is as shown below,

{"fault": {

"faultstring": "Failed to execute the RegularExpressionProtection StepDefinition RegExpProtection_JSONPayload. Reason: Unexpected duplicate key:last_name at position 2603.",

"detail": {"errorcode": "steps.regexprotection.ExecutionFailed"}

}}

Please suggest how to check the fault occurance in Regex so that I can customize the error in RaiseFault.

Solved Solved
0 6 385
1 ACCEPTED SOLUTION

adas
New Member
@RK4

The policy execution is being terminated when the regex policy error is encountered. In order to handle the error and give out your own error message through a fault rule please set the continueOnError=true in the regex policy. And then add a fault rule with a condition:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>RegularExpressionProtection</Name>
            </Step>
            <Step>
                <Condition>(regularexpressionprotection.failed equals true)</Condition>
                <Name>RaiseFault</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Please see the attached bundle. Here's a sample call to reproduce the error and you should see a 400 Bad Request instead of the out of the box 500 Server Error.

curl -v "http://myorgregexp-rev1-2016-02-15.zip-test.e2e.apigee.net/regexp/post" -d 'greeting=<script>alert(1)</script>'

View solution in original post

6 REPLIES 6

Not applicable

Any help on this above issue please?

I tried by giving all possible conditions.But I am still not able to capture the failured occured in Regex policy.

I tried with below conditions ,

<Condition>fault.name = "steps.regexprotection.ThreatDetected" </Condition>

<Condition>(regularexpressionprotection.RegExpProtection_JSONPayload.failed = "true") </Condition>

<Condition>(regularexpressionprotection.failed = "true") </Condition>

Still,the Raise fault is not invoked.Hence I am not able to customize the error thrown in Regex policy.

<PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>RegExpProtection_JSONPayload</Name>
            </Step>
            <Step>
                <Name>Raise-Fault-1</Name>
                <Condition>fault.name = "ThreatDetected"</Condition>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Not applicable

Hi team,

I am still waiting for the reply on this question.Please provide your inputs.

adas
New Member
@RK4

The policy execution is being terminated when the regex policy error is encountered. In order to handle the error and give out your own error message through a fault rule please set the continueOnError=true in the regex policy. And then add a fault rule with a condition:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>RegularExpressionProtection</Name>
            </Step>
            <Step>
                <Condition>(regularexpressionprotection.failed equals true)</Condition>
                <Name>RaiseFault</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Please see the attached bundle. Here's a sample call to reproduce the error and you should see a 400 Bad Request instead of the out of the box 500 Server Error.

curl -v "http://myorgregexp-rev1-2016-02-15.zip-test.e2e.apigee.net/regexp/post" -d 'greeting=<script>alert(1)</script>'

Thankyou @arghya das .This really helps me 🙂

@RK4 Glad that it was useful.

@Floyd Jones Can we add this to the documentation for regex protection policy so that its absolutely clear to the users, what needs to be done incase they want to give out their own customised error messages.

@arghya das, done. Thanks for the ping. Boy, I could have sworn we had a pointer to the fault handling topic, but looks like we didn't.