Default Fault Rule not adding CORS headers in Raise Fault

Google Cloud Apigee
,
1

Hi Team,

I am implementing CORS policy . I have added in CORS policy in pre flow and target pre flow and Options Preflight flow .

The issue I am getting whenever Default Fault Rule is called it is not adding CORS headers in response

CORS policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> CORS {request.header.origin} GET, PUT, POST, DELETE authorization, origin, x-requested-with, accept, content-type, referer * 3628800 false true true

RF-CommonError

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> { "errorCode": "{flow.error.code}", "errorType": "{flow.error.type}", "errorMessage": "{flow.error.message}" } {flow.error.status} {flow.error.reason} true true CORS AM-500InternalServerError 500InternalServerError RF-CommonError (fault.name != "RaiseFault")

AM-500InternalServerError this policy is to set default error message

can any one guide me on this issue

@dchiesa1

2

You need to attach the CORS policy once. In the Proxy Request preflow. Just one attachment.

https://youtu.be/OHbuqW_1fP0

3

Done Same thing but its giving error

has been blocked by CORS policy: No ā€˜Access-Control-Allow-Originā€™ header is present on the requested resource.

when the default fault rule is called .

Here I am setting up error messages based on conditions and its giving response in default fault rule

like oauthV2.OAuthV2-VerifyAccessToken.failed == true

I have added step for raise fault for custom error message format like

{
ā€œerrorCodeā€: ā€œ{flow.error.code}ā€,
ā€œerrorTypeā€: ā€œ{flow.error.type}ā€,
ā€œerrorMessageā€: ā€œ{flow.error.message}ā€
} getting these variable from fault rule assign message

(oauthV2.OAuthV2-VerifyAccessToken.failed == true) AM-401Unauthorized oauthV2.VA-APIKeyVerifier.fault.name == "oauth.v2.InvalidApiKeyForGivenResource" AM-500InternalServerError (fault.name = "QuotaViolation") AM-429QuotaError (fault.name Matches "ExecutionFailed") AM-InvalidSSO (CyberArkOAuthResponse.status.code != "200") AM-500InternalServerError RF-CommonError (fault.name != "RaiseFault") true
4

My suggestion: simplify your scenario to see what is really going on.

I just tried this in my Apigee X organization, and it works as expected.

I have a simple proxy with a CORS policy in the Preflow. And a conditional flow that calls VerifyAPIKey. That one does not always execute. The VerifyAPIKey is there, so that I can conditionally cause a fault.

The proxy has a DefaultFaultRule which injects a header into the response. The DFR will execute in the fault condition that occurs if the proxy executes the conditional flow that calls VerifyAPIKey, but there is no api key. I see the expected behavior from this proxy:

  • When there is an Origin header in the request, meaning it is a CORS request, then there are Access-Control-XX-XXX (CORS) headers in the response.
  • When there is no Origin header in the request, there are no Access-Control-* headers in the response.

This occurs whether there is a fault or not. In other words, Apigee is behaving as expected. (See the terminal session below) So there is something else going on wrong with yours.

Looking at your CORS policy, it may be that your Max-Age is set to 3628800, which equates to 42 days. Is it possible that your browser has cached an older version of the CORS response, and is relying on that older cache, and is never connecting with Apigee at all? If you would like to eliminate this as a possibility, use the browser developer tools and turn off the in-browser caching. (Google it if you donā€™t know which button to click)

Otherwise I donā€™t know what to suggest. Iā€™ve attached my proxy so you can try it in your environment.

My session:

$ curl -i $apigee/cors-loopback/t2 -H "Origin:http://localhost"
HTTP/2 200 
apiproxy: cors-loopback r4
content-type: application/json
access-control-allow-origin: http://localhost
access-control-expose-headers: *
access-control-allow-credentials: true
x-request-id: 02b7fdd2-ea30-47fb-8421-a85411fd5a97
content-length: 24
date: Wed, 24 Apr 2024 19:47:40 GMT
via: 1.1 google, 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{
    "status" : "ok"
}

$ curl -i $apigee/cors-loopback/t1 -H "Origin:http://localhost"
HTTP/2 401 
content-type: application/json
apiproxy: cors-loopback r4
access-control-allow-origin: http://localhost
access-control-expose-headers: *
access-control-allow-credentials: true
x-request-id: 7fadc9f9-c89f-444f-8c02-409f04b859d4
content-length: 150
date: Wed, 24 Apr 2024 19:47:45 GMT
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

$ curl -i $apigee/cors-loopback/t1                             
HTTP/2 401 
content-type: application/json
apiproxy: cors-loopback r4
x-request-id: f6a6351b-8665-4496-90fd-47e6f0318ac9
content-length: 150
date: Wed, 24 Apr 2024 19:47:55 GMT
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}
5

Hi

Thanks for the guidance.

The issue was in default fault rule raise fault policy.

It was not passing the Access-Control-Allow-Origin in response header even if the origin was present in the request .

For the solution I have updated the RF-CommonError

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> { "errorCode": "{flow.error.code}", "errorType": "{flow.error.type}", "errorMessage": "{flow.error.message}" } {flow.error.status} {flow.error.reason} {firstnonnull(request.header.origin,*)} true

by This solution its working now.

Guide me if required any changes

6

Yes, two things

  1. Do not use RaiseFault in a FaultRule. It is an anti-pattern (details here). If you need to set the response in a FaultRule, including in DefaultFaultRule, you should use AssignMessage.
  2. I donā€™t think you should need to explicitly set a header in an AssignMessage. If you use the CORS policy, it will apply access-control header as appropriate in the response. See the bundle i attached in my prior reply. It shows the correct way.

It could be that using a RaiseFault in a FaultRule is causing the problem, which requires you to set a header in AssignMessage.

7

Thanks for the help ,

It worked with adding Assign Message instead of Raise Fault .

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> AM-CommonError { "errorCode": "{flow.error.code}", "errorType": "{flow.error.type}", "errorMessage": "{flow.error.message}" } {flow.error.status} {flow.error.reason} true