Solved: apigee CORS HEADERS.

Mesun · 11-12-2022 01:15 AM

I have a variant of the standard CORS wherein the number of headers are not really fixed. So even after following the standard apigee documentation, adding-cors-support-api-proxy We keep adding the headers in allowed headers as given below.

<Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, authorization, KEEP adding Many keywords here. </Header>

So our headers list has been growing over time and we need to ignore the header in the options call or have a way to deal with it.

Kindly help with an alternative as we have tried few things but basically the option call can send any header and we cant manage all headers. Finally if the header is not added to the list then the option call results in CORS errors at the UI side.

dchiesa1

@Mesun wrote:

Kindly help with an alternative as we have tried few things but basically the option call can send any header and

Yes, this is the design of CORS. This is not particular to the use of Apigee.

we cant manage all headers

The theory behind CORS is that the service defines the interface, and that includes which combinations of verbs, paths, and headers can be sent. And then clients conform to that request. CORS allows a server to distinguish between different clients based on the origin. So origin1 may be allowed to do X and Y, while origin2 may be permitted to do only X. (Where X and Y are combinations of headers and verbs and etc).

The OPTIONS call is a way a user-agent will ask the server, "May I do this?" and it is up to the server to response "yes, it's ok" or "no, it's not ok." If you WANT To allow all of those headers, then you need to update your CORS preflight response to include those headers. If you DO NOT want to allow those headers, then you should not include those headers in allow-headers. If the client is sending headers that are not part of the documented interface, then the server should respond appropriately, and disallow the call.

This is all standard CORS function. None of this is particular to the use of Apigee to manage APIs that support CORS. You'd have to do this stuff, whether or not you use Apigee. Apigee (particularly hybrid and X) has features that can make management of CORS a little easier. But whether or not you use Apigee, you still have to do the stuff I described above.

View solution in original post

dchiesa1

@Mesun wrote:

Kindly help with an alternative as we have tried few things but basically the option call can send any header and

Yes, this is the design of CORS. This is not particular to the use of Apigee.

we cant manage all headers

The theory behind CORS is that the service defines the interface, and that includes which combinations of verbs, paths, and headers can be sent. And then clients conform to that request. CORS allows a server to distinguish between different clients based on the origin. So origin1 may be allowed to do X and Y, while origin2 may be permitted to do only X. (Where X and Y are combinations of headers and verbs and etc).

The OPTIONS call is a way a user-agent will ask the server, "May I do this?" and it is up to the server to response "yes, it's ok" or "no, it's not ok." If you WANT To allow all of those headers, then you need to update your CORS preflight response to include those headers. If you DO NOT want to allow those headers, then you should not include those headers in allow-headers. If the client is sending headers that are not part of the documented interface, then the server should respond appropriately, and disallow the call.

This is all standard CORS function. None of this is particular to the use of Apigee to manage APIs that support CORS. You'd have to do this stuff, whether or not you use Apigee. Apigee (particularly hybrid and X) has features that can make management of CORS a little easier. But whether or not you use Apigee, you still have to do the stuff I described above.