[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