Always Generic ExecutionFailed fault instead of detailed fault for JSONThreatProtection

[yassertaeima]

Private Install Version 4.17.09

We have set the org property

{
"name": "features.isPolicyHttpStatusEnabled",
"value": "true"
},

as per the usage notes in

https://docs.apigee.com/api-platform/reference/policies/xml-threat-protection-policy#usagenotes-thre...

The response is still 500 and we are still seeing the JSONThreatProtection raising fault ExecutionFailed, not the detailed fault (e.g. ExceededObjectEntryNameLength) .

Is there another setting to raise the detailed fault instead of the generic ExecutionFailed?

[yassertaeima]

Has anyone been able to get this JSON Threat Policy to generate the fault.name value other than ExecutionFailed? or 400 instead of 500?

As per the release notes for 4.15.07

https://docs.apigee.com/release/notes/4150700-apigee-edge-private-cloud-release-notes

The org property features.isPolicyHttpStatusEnabled should provide the expected behavior, but even with that property set to true we are still receiving 500 and ExecutionFailed.

This is not the correct HTTPStatusCode; 500 means internal error in server processing, but sending invalid JSON is not a 500 Internal server error, it should be 400 Bad request because it is invalid user input and as per HTTP Error Code specification 400 is not a retry-able error unless the user correct the input data, but 500 indicates that the issue is with in the processing server and should be corrected by the processing server.

Has anyone been able to get this JSON Threat Policy to generate the fault.name value other than ExecutionFailed? or 400 instead of 500?

[rmishra]

When a JSON threat is detected, Apigee will populate a context variable called jsonattack.failed and set its value to true.

If a threat is detected, the flow is short circuited to error handling(FaultRules).In Fault Rules, you can now write a conditional step to customize the error which is returned to the api client(including http error code), Next use a "Raise Fault" policy to return the customized error instead of the original error.

You can also refer https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html for a consistent error handling strategy within Apigee

[yassertaeima]

Thanks @rmishra, but this is not what the spec lists. it lists a set of faults that should be in the fault.name

===========

fault.name = [error_name][error_name] = The specific error name to check for as listed in the table above.fault.name Matches "SourceUnavailable"

===========

We are unable to get any of the fault.name values listed in the spec (e.g.

SourceUnavailable, ExceededObjectEntryNameLength); we are only getting ExecutionFailed

I understand that

https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html describes how to handle the fault, but the issue is we are not getting the correct fault.name value

[rmishra]

Ok.

I was responding to the part where you asked if anybody was able to customize the error returned and switch the error code from 500 to 400

We did and hence the original response. Hope you find some real answers though.