Handle Cross Domain issues in Gateway

[Nicolas.Afonso]

Hi folks !

 

My question today is about cross-domain validation.

I implemented some proxies APIs and today I want to call them from my website via Ajax calls.

 

Nevertheless I am facing issue with cross-domain validation, my browser refusing to handle the response displaying this error message :

XMLHttpRequest cannot load https://api.rec-env.com/someProxyAPI. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.website.com' is therefore not allowed access. The response had HTTP status code 500.

Could you give me the best practices to handle such cases ? From my point of view, I have to set the "Access-Control-Allow-Origin" response header to "*" (wildcard) value because these APIs will in the future be used by clients' browsers, servers, .. I do not want to have a huge list of domains/protocols authorized.

 

Secondly is it possible to systematically set a header value for request / response messages ? In this specific case if this solution is viable I want all my futures APIs responses include this header.

I look forward hearing from you

 

Thank you

[ucisa01]

Hi,

 

Letting any site access your endpoint (the wildcard) seems like it defeats the purpose of CORS? The server is supposed to send back a list of origins that it deems acceptable during the pre-flight phase of the negotiation.

 

I don’t think a wildcard would be accepted…unless allow-creds resp header is set to false, but then you could have an auth problem.

 

Thanks, Sam

 

Sam Ucich | Sr. Principal Consultant, CA API Management

603.548.3841 | [e-mail]

[Nicolas.Afonso]

Hi Samuel,

 

Thank you for your answer.

 

Allowing all origin domains is not an issue for me, I protect my APIs through several other steps.

 

About pre-flight phase : from my understanding of the solution I have to handle this exchange and make some processing when I detect an HTTP OPTIONS verb. Nevertheless it is a very common issue that your clients must face (consume APIs proxies using web client) ... Could you give me your best practices for handling this ? I can't believe this pre-flight case has to be implemented by service developers and not automatized by the Gateway.

[ucisa01]

Hi,

 

Have a look at the attached policy…

 

Thanks, Sam

 

Sam Ucich | Sr. Principal Consultant, CA API Management

603.548.3841 | [e-mail]

Attachment(s)

corsprotected.xml.zip   2 KB 1 version

[Nicolas.Afonso]

Thank you for you kind support.

 

There is an encapsulated assertion in your policy : "Enforce CORS". Could you send it to me ?

 

So if I understood correctly this pre-flight phase logic has to be implemented by devs, and not included natively like other API Gateway did (Apigee Edge for example).

[ucisa01]

Hi,

 

Sure np…attached is the ecap.

 

I’m not well versed in Apigee Edge, so I don’t know the answer.

 

These artifacts are from a demo to show POC for using OAuth with a browser (or a JSOC – javascript oauth client), and since Ajax was employed it had to support Cors. See attached diagram…and note, this was only a POC and not a production solution, because the OAuth token is sent back to the browser as a clear text parameter…so not very secure.

 

Thanks, Sam

 

Sam Ucich | Sr. Principal Consultant, CA API Management

603.548.3841 | [e-mail]

Attachment(s)

Enforce-CORS-Encap-v2.xml.zip   4 KB 1 version

jsoc_architecture2.pdf   141 KB 1 version

[Nicolas.Afonso]

Dear Samuel,

 

Thank you for your quick reply and your attached files.

 

In conclusion CORS handling logic has to be implemented by services developers in CA API Gateway.

 

Have a very nice day