CORS policies headers fail

[murhaforarticle]

Hi everyone,

I've got a problem.

I would like to use Apigee Spec swagger, but it produced "Access to fetch at 'https://xxx' from origin 'https://apigee.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." error.

I adjusted my endpoints as it was defined there https://docs.apigee.com/api-platform/develop/adding-cors-support-api-proxy

I created standard policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="add-cors">
<DisplayName>Add CORS</DisplayName>
<FaultRules/> 
<Properties/> 
<Set>
	<Headers>
		<Header name="Access-Control-Allow-Origin">*</Header>
		<Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, authorization</Header>
		<Header name="Access-Control-Max-Age">3628800</Header>
		<Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header>
	</Headers> 
</Set> 
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="false" transport="http" type="response"/> 
</AssignMessage>

and put it in all flows and in requests and responses sections.

It does not have any effect.

I do not have this headers on response:

Which could be a season of that?

Thank you!

[murhaforarticle · Accepted solution]

Seems, I have found something.

Swagger UI in APIs Specs sends "Authorization: BearerToken ..." instead on "Authorization: Bearer ..."

Token check fails and error response is returned back to the browser without of CORS headers.

Trying to overcome that.

Seems its Apigee Swagger issue

[dchiesa1]

I would like to use Apigee Spec swagger,

FWIW, I don't know exactly what that is. But maybe it is unrelated to the CORS problem you're observing.

Which could be a reason of that?

I don't know the reason, CORS is kind of tricky to get right.

I suggest you use your browser's "developer tools" tab to check the network requests that are being sent out. At the same time use Apigee Trace for the API proxy. You should be able to see source of the problem.

This screencast covers the new CORS policy that is available in Apigee X and Apigee hybrid. If you are using one of those then I suggest that you use the new policy rather than following the older documentation that you linked to. Even if you don't have X or hybrid, the screencast may still be useful to you because I take the first few minutes to explain CORS and describe what it does. And then I show you how to use developer tools in the browser and the Trace in Apigee to follow the requests. This technique may be helpful to you, even if you can't take advantage of the new policy.

Keep in mind:

• A browser may cache the CORS response. The intent of the -Max-Age header is to tell the browser, for how long the response is cacheable. This means if you were fiddling around with the CORS policy and configured your proxy to send something not-quite-right during development, the browser may be caching it. You can turn off caching if you open the developer tools window in your browser. (See my screencast, I believe I make a quick mention for how to do it. If not, google around for "how to turn off caching in developer tools" or something like that.)
• The Authorization header is special. It does not belong in the -Allow-Headers header in your CORS response. Instead you must send back Access-Control-Allow-Credentials: true. See this link for more on this.
• Check to see that all the other headers you're sending from your web browser are included in the -Allow-Headers header in the CORS response.
• Also double check that you've attached the CORS policy in the right places, and that you have a flow for the OPTIONS (preflight) request.

If you still cannot diagnose the problem, then I suggest you take a trace of the exchange, download the trace, and then post THAT here on community. It will allow people to view in their Apigee UI, the trace that you see.

[murhaforarticle]

Thank you very much for you suggestions!

I really appreciate time you spent on it!

Unfortunatelly, nothing helped.

I successfully adjusted pre-flight check (OPTIONS), but nothing more.

And... Moreover, I see CORS header in Postman, curl etc. responses.

I have to clarify conditions:

I use Apigee OAuth2.

And without of token verification policy all is ok.

But when I add this policy, I see that error in browser console (using swagger API Spec and Portal).

Any idea in this case?

Thank you very much one more time

[dchiesa1]

without of token verification policy all is ok.

I think changing the API proxy definition to exclude the token verification policy..... should not change the CORS dialogue. That token verification policy is an internal detail, and its presence or absence should not affect the messages being exchanged by the browser and the API proxy.

I think there must be something more that is implied by "without token verification policy". Maybe you are changing the request in some way; for example, not transmitting the Authorization header in the case where the token verification policy is not used within the API Proxy.

In that case then you need to look at the Access-Control-Allow-Credentials header, and insure that it is included in the Pre-flight response as well as in other CORS responses.

I know CORS is complicated, getting CORS to work with any system is tricky. The steps I outlined above are all the suggestions I have for diagnosing and troubleshooting.

If this problem proves to be hard to solve, I suggest breaking it down into simpler units. Simplify radically. Take it one step at a time. Insure that GET requests work. Insure that GET requests with an Authorization header work. After you get that working, then add POST operations. Add different paths. Different content-types. Other headers you need to pass.

One step at a time.

This tool might assist as you work through those steps.

https://dinochiesa.github.io/cors-demonstrator/

You can configure it to point to your own API Proxy endpoint, and try multiple different requests, verifying each step.

I am not sure you could do the same in Postman. I think it does not observe the CORS restrictions. You need a browser to exercise CORS.

[murhaforarticle]

Thank you!

I will try that...

It is really very strange situation because I see CORS header on each steps of the flows.

And Postman, online browser Postman works.

Will try to do something with that.

If I find answer, will post it.

Nevertheless Dino-at-Google ♦♦, thank you!

[sillan_dt]

Can you check the response from backend is correct or not?

Also can you try cors headers to * in all other than time?

Also remove this policy from all request flows and response flows. Only add it to response of proxy endpoint preflow.

[murhaforarticle · Accepted solution]

Seems, I have found something.

Swagger UI in APIs Specs sends "Authorization: BearerToken ..." instead on "Authorization: Bearer ..."

Token check fails and error response is returned back to the browser without of CORS headers.

Trying to overcome that.

Seems its Apigee Swagger issue

[dchiesa1]

Yes - it's a bit tricky to send the right headers back ... in the case of faults. You may need a defaultFaultRule in your proxy endpoint. Something like this:

  <DefaultFaultRule name="default-fault-rule">
    <Step>
      <Name>AM-InsertCorsHeaders</Name>
    </Step>
    <AlwaysEnforce>true</AlwaysEnforce>
  </DefaultFaultRule>

[murhaforarticle]

Yeap, it is very important comment. Thank you!

[murhaforarticle · Accepted solution]

Yes, It was token issue with Apigee Swagger...

I just used

securitySchemes:
    BearerAuth:
      type: http
      scheme: bearer

instead of OAuth2 and

added

security:
- BearerAuth: []

to the endpoins definition

And input token instead of creds.

And ApiSpecs started working.

The reason: I did not added headers on error responses.

Thats it.

Hope it will be useful for another.

[kurtkanaskie]

Regarding:

Swagger UI in APIs Specs sends "Authorization: BearerToken ..." instead on "Authorization: Bearer ..."

There's an issue with the default behavior of Apigee OAuth token generation in that is sets "BearerToken" instead of "Bearer". See https://docs.apigee.com/api-platform/reference/policies/oauthv2-policy#non-rfc-compliant-behavior for details and a suggested solution. The Spec viewer and many other tools use the value returned in the token_type property.

[nehakushwaha]

Hi,

i am facing same issue Access to XMLHttpRequest at 'resource url' from origin 'https://ssss' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

i tried all the above approaches, none worked for me. any suggestion?

using below cors Assign message policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM.CORSHeaders">
<DisplayName>AM.CORSHeaders</DisplayName>
<Set>
<Headers>
<Header name="Access-Control-Allow-Credentials">true</Header>
<Header name="Access-Control-Allow-Origin">*</Header>
<Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, Authorization, apikey</Header>
<Header name="Access-Control-Max-Age">3628800</Header>
<Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE, HEAD, PATCH</Header>
</Headers>
</Set>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Added OptionsPreFlight, NoRoute, CORS in DefaultFaultRule. but still same error. 

[dchiesa1]

This is a "solved" question from 3 months ago. 

When people post new questions as comments to existing solved questions, they're very hard to find and track. 

As a result those new questions can effectively be "hidden", and they will get less attention. 

Please post a new question if you have a new question. You can reference this existing question , if that's helpful. 

[nehakushwaha]

Missed this detail in above comment

I have two APIProxy in APIGEE EDGE and both proxy contain exact same revision. From proxy 1 being deployed to portal does not give any error but when i deploy proxy2 with exact same revisison and specs it give me : XMLHttpRequest at 'resource url' from origin 'https://ssss' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

i am not sure what i am missing here.