[Apiman-user] Client App and CORS
Marc Savy
marc.savy at redhat.com
Fri Aug 12 11:20:24 EDT 2016
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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160812/47de9005/attachment.html
More information about the Apiman-user
mailing list