[Apiman-user] APIMan return error 400 for header Access-Control-Request-Method

[Ashish Patel]

My two cent on below… Sorry if it spams your inbox.

The CORS Policy Preflight request, as per specification has to be a GET request and so if we use APIMan CORS Policy, we have to send the “apiKey” in get Request. We faced this issue and so sharing our experience (Preflight request was not sending apiKey as we configured in Header).
Agree, sending “apiKey” through GET is not recommended, but this is CORS preflight spec restriction and we have to leave with it. Any thoughts on how APIMan can help avoid that ? (allow preflight without apiKey on CORS request ?).

From: apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Marc Savy
Sent: Wednesday, December 19, 2018 01:42
To: Renato Barros
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method

No problem, glad we cleared it up!

On Tue, 18 Dec 2018 at 17:55, Renato Barros <renalexster at gmail.com<mailto:renalexster at gmail.com>> wrote:
Sorry Marc,

I misunderstood the concept of CORS and the plugin. My APIs are already prepared to use CORS requests. So that, I even don't need to create a CORS Policy in the APIMan.

On Tue, 18 Dec 2018 at 14:29, Renato Barros <renalexster at gmail.com<mailto:renalexster at gmail.com>> wrote:
Thanks for your reply Marc,

About the OPTIONS request: It results from the preflight request, so it's not the real request. My frontend is attempting to do a POST request. However, before this, a preflight is sent to the server automatically. The matter is The Preflight Request Fails


The POST request works.

My question is: Is there some problem with my CORS Policy? Should I disable (turn False) Terminate on Cors Error? Or It's the result of some CORS plugin problem?

On Tue, 18 Dec 2018 at 14:04, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
Just to confirm: the purpose of the CORS plugin is to provide a CORS frontend to a service which does not currently have CORS. It is not to bypass CORS on a backend service that *already* has CORS.

I believe you may be misunderstanding how the CORS protocol works.

From my recollection, if you are doing a non-simple request (such as yours), then you must execute a preflight request first (which is a special type of OPTIONS request -- https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests).

The browser first executes the preflight request, THEN it separately and subsequently executes the real request. So, if you were attempting to execute an OPTIONS request then you would execute 2 separate calls. This is done on your behalf transparently by the browser.

The 'real' call is approved by virtue of the preflight request, and does not require the CORS headers you're including (which make it look like a preflight request).

Please see: https://mdn.mozillademos.org/files/16401/preflight_.png

If you are doing a *simple* request, as per the CORS specification, then no preflight is required and you embed the headers in the 'real' request as your samples show.

Does this resolve your issue?

On Tue, 18 Dec 2018 at 12:59, Renato Barros <renalexster at gmail.com<mailto:renalexster at gmail.com>> wrote:
Hello Marc,

I don't think the problem is associated with Access-Control-Allow-Origin. Below there are two requests using Restlet Client, the first one works without the Header Access-Controle-Request-Method, the second only adding this Header gets fail.



On Tue, 18 Dec 2018 at 09:40, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
I think your issue might be the way that you're formulating your request.

In order to issue a valid CORS request, you must set your origin header. You should probably try that first.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

e.g. curl ... -H "Origin: mymachine.local"

When using a browser, this is usually issued on your behalf. But, if you're using curl, it won't be.


On Tue, 18 Dec 2018 at 12:35, Renato Barros <renalexster at gmail.com<mailto:renalexster at gmail.com>> wrote:
Hi Marc,

I've just updated the image with details. The Access-Control-Allow-Origin already had "*" as value.

On Tue, 18 Dec 2018 at 05:50, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
I'm not sure why your browser isn't rendering it, but there should be a list in the Access-Control-Allow-Origin section that would allow you to add an entry such as "*" or "foo.com<http://foo.com>".

What is your setup?

On Mon, 17 Dec 2018 at 19:10, Renato Barros <renalexster at gmail.com<mailto:renalexster at gmail.com>> wrote:
Hello all,

I'm getting an error with Access-Control-Request-Method Header in my APIs.

I posted details in StackOverflow<https://stackoverflow.com/questions/53821510/apiman-return-error-400-for-header-access-control-request-method>.

Please, someone could help me?
_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org<mailto:Apiman-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user
Accept the Challenge. Go Paperless
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181219/b21f119d/attachment-0001.html