4:45 p.m.
Dears,
I've created a "client app" that has a lot of contracts with a lot of APIs.
I'm having the following problem:
In Cross-origen, when the browser send a OPTIONS request, it does not send
the parameter X-API-Key. Then, the apiman returns a error: "API not public".
Is possible to disable the X-API-Key validation of a "client app" when the
request is OPTIONS type?
Thanks,
Harry
10:20 a.m.
Hi Harry,
As an interim option you can transmit the key as a query parameter instead
of a header (e.g. /a/b/c/?apiKey=FOO).
But, I think you're right. As I understand the CORS spec, we should always
allow an OPTIONS requests to (minimally) enter the policy chain, because
browsers don't make a CORS preflight request with any custom headers (they
simply don't transmit them).
Under certain circumstances it might allow a client to hit a backend
without a key when we don't want it to. Although I imagine the impact of
this should generally be quite minimal.
Others: Any thoughts?
On 10 August 2016 at 22:45, Harry Trinta <harrytpc(a)gmail.com> wrote:
Dears,
I've created a "client app" that has a lot of contracts with a lot of
APIs.
I'm having the following problem:
In Cross-origen, when the browser send a OPTIONS request, it does not send
the parameter X-API-Key. Then, the apiman returns a error: "API not public".
Is possible to disable the X-API-Key validation of a "client app" when the
request is OPTIONS type?
Thanks,
Harry
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
11:08 a.m.
The problem with doing that is: how do we know what app is being used?
And then, what happens if the CORS policy was configured either on the
application or on the plan? Without the API key we won't know what app
is making the call and we also won't know what plan to use.
Perhaps a better solution is to handle CORS pre-flight requests
separately? Before the request ever even reaches the apiman policy
engine. It would be a relatively simple thing to implement a
CorsPreflightOnlyFilter in the servlet implementation of the apiman gateway.
However, isn't there specific pre-flight related information configured
in the CORS policy itself? So perhaps a global filter wouldn't work
well enough (since it wouldn't have information to those config settings).
The best approach *may* be to pass the api key in the URL.
-Eric
On 8/12/2016 11:20 AM, Marc Savy wrote:
Hi Harry,
As an interim option you can transmit the key as a query parameter
instead of a header (e.g. /a/b/c/?apiKey=FOO).
But, I think you're right. As I understand the CORS spec, we should
always allow an OPTIONS requests to (minimally) enter the policy chain,
because browsers don't make a CORS preflight request with any custom
headers (they simply don't transmit them).
Under certain circumstances it might allow a client to hit a backend
without a key when we don't want it to. Although I imagine the impact of
this should generally be quite minimal.
Others: Any thoughts?
On 10 August 2016 at 22:45, Harry Trinta <harrytpc(a)gmail.com
<mailto:harrytpc@gmail.com>> wrote:
Dears,
I've created a "client app" that has a lot of contracts with a lot
of APIs.
I'm having the following problem:
In Cross-origen, when the browser send a OPTIONS request, it
does not send the parameter X-API-Key. Then, the apiman returns
a error: "API not public".
Is possible to disable the X-API-Key validation of a "client app"
when the request is OPTIONS type?
Thanks,
Harry
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user
<https://lists.jboss.org/mailman/listinfo/apiman-user>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
3026
days inactive
3028
days old
2 comments
3 participants
participants (3)
-
Eric Wittmann -
Harry Trinta -
Marc Savy