Layer7 API Management

In our policy we are using Stop Processing assertion whenever any validation fails.

For example:

1.  At Least Once Assertion Must Evaluate to true

   1.1 All Assertions Must Evaluate to true

      1.1.1 Check for any Code Injection issues

   1.2 All Assertions Must Evaluate to true

      1.2.1 Customize Error Response

      1.2.2 Stop Processing

When ever policy execution reaches to Stop Processing assertion API is responding with Unhandled exception. Not with Customize error response. 

What could be the reason for this? 

Regards

Kareem

Kareem,

Good Afternoon. Have you tried to run the Service Debugger through to see where the policy walks through? I've tried the logic with the following policy and I receive back the correct response on a 9.1 Gateway when it fails the code injection.

<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
    <wsp:All wsp:Usage="Required">
        <wsp:OneOrMore wsp:Usage="Required">
            <wsp:All wsp:Usage="Required">
                <L7p:CodeInjectionProtectionAssertion>
                    <L7p:IncludeBody booleanValue="true"/>
                    <L7p:IncludeUrlPath booleanValue="true"/>
                    <L7p:IncludeUrlQueryString booleanValue="true"/>
                    <L7p:Protections codeInjectionProtectionTypeArray="included">
                        <L7p:item protectionType="htmlJavaScriptInjection"/>
                        <L7p:item protectionType="phpEvalInjection"/>
                        <L7p:item protectionType="shellInjection"/>
                        <L7p:item protectionType="ldapDnInjection"/>
                        <L7p:item protectionType="ldapSearchInjection"/>
                        <L7p:item protectionType="xpathInjection"/>
                    </L7p:Protections>
                    <L7p:Target target="REQUEST"/>
                </L7p:CodeInjectionProtectionAssertion>
            </wsp:All>
            <wsp:All wsp:Usage="Required">
                <L7p:CustomizeErrorResponse>
                    <L7p:ExtraHeaders nameValuePairArray="included"/>
                </L7p:CustomizeErrorResponse>
                <L7p:FalseAssertion/>
            </wsp:All>
        </wsp:OneOrMore>
        <L7p:HardcodedResponse>
            <L7p:Base64ResponseBody stringValue="PFN1Y2Nlc3MvPg=="/>
        </L7p:HardcodedResponse>
    </wsp:All>
</wsp:Policy>

Sincerely,

Stephen Hughes

Director, CA Support

Hi Stephen,

Thanks for the response:

I have realized the reason for Unhandled exception response is Global Fragment declared as below:

Policy Type: Global Policy Fragment
Policy Tag: Message Completed.

Customozie error: Unhandled Exception, Response Code: 503

- I believe Global fragments of type 'message completed' should executed on all cases irrepective of success or failure of the policy
- Why this response is not returned with policy completes successfully? This executes only when Stop Processing or Raise error assertions are executed.

- Is there a way to configure not to execute this Global Policy Fragments(message completed) for my policy(service)?

Regards

Kareem

Kareem,

You are correct that the global policy will execute on all execution of the policies. The only way to bypass would be to include logic to pass through in your global policy based on certain response from the main policy.

Sincerely,

Stephen Hughes

Director, CA Support

Hi Stephen,

Can you elaborate on logic to pass through global policy? Please provide an example to bypass this.

Regards

Kareem

Kareem,

The policy logic will need to be modified based on the logic in the global policy as the default policy is blank. The simpliest way would be to have at lease one branch with the second branch being continue processing if the primary logic fails.

Sincerely,

Stephen Hughes

Director, CA Support

Hello Stephen

We have found another workaround. We have used 'Return Template Response to Requestor' assertion instead of Custom Error Response and checked the option 'Send Response Immediately'. 

This way I believe this assertion is responding to the requestor before Global Fragment (Message complete) gets executed. 

But I am not sure is there any side-effects of using approach?

Why do we have two different response assertions( 'Return Template Response to Requestor'  and  'Custom Error Response') which are doing almost the same funtionality?

Regards

Kareem

Kareem,

The checkbox for send response immediately will not wait until the end of the policy to send the response. This will cause the response to be sent and the connection will be closed so keep alives will not be maintained.

The difference between the Return Template Response to Requestor and Custom Error Response is that the custom error response will trigger when any assertion branch fails without traversing the rest of the policy where the Template assertion will need to be built into a failure branch.

Sincerely,

Stephen Hughes

Director, CA Support

Instead of setting your generic error response in 'message completed' set it in your 'message recieved' so that you can overload it.