How can i set up CORS which checks if an OPTIONS request (Preflight request) is triggered before every POST request.

[#1]

How can i set up CORS which checks if an OPTIONS request (Preflight request) is triggered before every POST request.

The requirement is that before every POST request Apigee has to check if an OPTIONS request was triggered and if CORS headers were set.

If a preflight request/OPTIONS request was not triggered then the POST request has to be denied and 401 has to be sent back

[anilsr]

Dear @dj1 ,

Did you get a chance to check documentation here ?

[anilsr]

Dear @dj1 ,

Documentation here explains how to setup CORS Setup for API Proxy & Handling CORS preflight requests. In my opinion server / api proxy sends back preflight request with responses include which origins the server will accept CORS requests from, a list of HTTP methods that are supported for CORS requests, headers that can be used as part of the resource request, the maximum time preflight response will be cached, and others. Generally using the preflight response, check will be done on client side to initiate actual POST / Any other method call to server again.

Access-Control-Max-Age (optional) - Making a preflight request on *every* request becomes expensive, since the browser is making two requests for every client request. The value of this header allows the preflight response to be cached for a specified number of seconds.

Once the preflight request gives permissions, the browser makes the actual request. The actual request looks like the simple request, and the response should be processed in the same way:

Any reason why you would like to do same in API Proxy itself ?

Cheers,

Anil Sagar

[#4]

If there is a slight change in the POST request url or with some parameter sent then by default the browser sends in a preflight request. In my case there is a change in the request that is sent everytime.

So now the requirement is that before every POST request I have to check if there was an OPTIONS request sent previously. I am not sure if i can achieve this since http is stateless and remembering the verb of previous request would be tedious. Apparently TomCat server does this, so can we do this on Apigee server too? I hope i have conveyed it well. Let me know if I have to provide more details

[#5]

Hi - we have found that the recommended method for handling this does not serve our needs, and have adopted a slightly different approach. I would like to share this w/ the community, but only after someone from APIGEE has a chance to look at it....

[jovaniac]

hey guys, I implemented something like that and it served me correctly.

In the proxy enpoint we must place in the preflow the next call of a Flowcallout to invoke a sharedflow which will have the policy of CORS

<PreFlow name="PreFlow">
<Request>
<Step>
<Name>FC-CORS</Name>
</Step>
<Step>
<Name>FC-OAuth2</Name>
</Step>
</Request>
<Response/>
</PreFlow>

Definition of flowcallout, where we invoke the sharedflow

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<FlowCallout async="false" continueOnError="false" enabled="true" name="FC-CORS">
<DisplayName>FC-CORS</DisplayName>
<FaultRules/>
<Properties/>
<SharedFlowBundle>OPTIONS-CORS-Headers-Response</SharedFlowBundle>
</FlowCallout>

definition of sharedflow

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SharedFlow name="default">
<Step>
<Name>OPTIONS-CORS-Headers-Response</Name>
<Condition>request.verb == "OPTIONS"</Condition>
</Step>
</SharedFlow>

definition of the policy of raisefull, where we will indicate the headers of Access-Control-Allow-Origin with * that will allow the invocation from our browser

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="OPTIONS-CORS-Headers-Response">
<DisplayName>OPTIONS CORS Headers Response</DisplayName>
<Properties/>
<FaultResponse>
<Set>
<Headers>
<Header name="Access-Control-Allow-Origin">*</Header>
<Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, ucsb-api-key, ucsb-api-version, authorization</Header>
<Header name="Access-Control-Max-Age">3628800</Header>
<Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header>
</Headers>
<Payload contentType="text/plain"/>
<StatusCode>200</StatusCode>
<ReasonPhrase>OK</ReasonPhrase>
</Set>
</FaultResponse>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

Regars