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(a)lists.jboss.org [mailto:apiman-user-bounces@lists.jboss.org] On
Behalf Of Marc Savy
Sent: Wednesday, December 19, 2018 01:42
To: Renato Barros
Cc: apiman-user(a)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@gmail.com<mailto:renalexster@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@gmail.com<mailto:renalexster@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@redhat.com<mailto:marc.savy@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@gmail.com<mailto:renalexster@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@redhat.com<mailto:marc.savy@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@gmail.com<mailto:renalexster@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@redhat.com<mailto:marc.savy@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@gmail.com<mailto:renalexster@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-retu...;.
Please, someone could help me?
_______________________________________________
Apiman-user mailing list
Apiman-user@lists.jboss.org<mailto:Apiman-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user
Accept the Challenge. Go Paperless