<div dir="ltr">Great! Global CORS could be awesome and useful!<br><br><div>In general I'm using API Key to use some security policies. My policies involves IP address white list, oauth integration with keycloak, and roles verification. Also, I used a validation about the number of requests filtered by IP Address to avoid DDoS or web crawlers.</div><div>So, there is some difficulties...</div><div><br></div><div>When I'm using javascript and mobile apps, I don't know if would be possible to use the white list. I've never tried to test that. but, using integration with keycloak gives me a security level, so that's ok to me!</div><div><br></div><div>Thanks for your answer!</div><div><br></div><div>Best Regards,</div><div><br></div><div>Celso Agra</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-02 17:40 GMT-03:00 Marc Savy <span dir="ltr"><<a href="mailto:marc.savy@redhat.com" target="_blank">marc.savy@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a good area of discussion.<br>
<br>
There are some caveats to the query parameters approach. Query params<br>
are sometimes stored in logs and other areas where you wouldn't want<br>
highly sensitive data being kept.<br>
<br>
I think in the Apiman API Key case it should be okay, but it depends<br>
on your use case:<br>
<br>
- The API Key is only to provide correlation between an inbound<br>
request and an Apiman Client; it doesn't really provide security. For<br>
example, you would generally still need to do OAuth2, JWT, BASIC or<br>
some other security mechanism over the top if you want "real" auth and<br>
authz.<br>
<br>
- The Apiman Gateway strips out the apikey query parameter (i.e. it<br>
doesn't get passed to the backend). However, if you terminate SSL<br>
before the Apiman Gateway then it might have a chance to be stored in<br>
some logs elsewhere.<br>
<br>
For example, using my echo service (just responds back with what it receives):<br>
<br>
}[msavy@mmbp apiman](list-prototype)$ curl -k<br>
'<a href="https://localhost:8443/test/froofroo/9003?apikey=7ab94cd5-6d31-4ed0-ba8a-607b2cbe0bc9&another=thing" rel="noreferrer" target="_blank">https://localhost:8443/test/<wbr>froofroo/9003?apikey=7ab94cd5-<wbr>6d31-4ed0-ba8a-607b2cbe0bc9&<wbr>another=thing</a>'<br>
{<br>
"method" : "GET",<br>
"resource" : "/a/b/c/?another=thing", (1)<br>
"uri" : "/a/b/c/",<br>
"headers" : {<br>
"Transfer-Encoding" : "chunked",<br>
"Accept" : "*/*",<br>
"User-Agent" : "curl/7.54.0",<br>
"Host" : "localhost:9999"<br>
},<br>
"bodyLength" : null,<br>
"bodySha1" : null,<br>
"counter" : 6<br>
<br>
(1) Notice that the apikey query parameter has not appeared in the<br>
echoed response<br>
<br>
<br>
As a fairly rough solution, perhaps we could allow people to<br>
additionally set a global CORS config on the Apiman Gateway (e.g. in<br>
your case where you control the entire gateway this could be a useful<br>
'base case').<br>
<div class="HOEnZb"><div class="h5"><br>
On 2 October 2017 at 19:52, Celso Agra <<a href="mailto:celso.agra@gmail.com">celso.agra@gmail.com</a>> wrote:<br>
> I understand!<br>
><br>
> I got this conflict because part of my application is made in angular4.<br>
> I'm using apikey as a query param, but this was a question to me "is this<br>
> right put apikey as query param?"<br>
><br>
> I believe there is no problem leave this as query param, since url is also<br>
> encrypted.<br>
><br>
> Thanks for your attention Eric and Marc!<br>
><br>
><br>
> 2017-10-02 15:22 GMT-03:00 Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>>:<br>
>><br>
>> Correction:<br>
>><br>
>> I think that we can provide full functionality in all<br>
>> circumstances.<br>
>><br>
>> I think that we *cannot* provide full functionality in all<br>
>> circumstances.<br>
>><br>
>> On 2 October 2017 at 19:21, Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>> wrote:<br>
>> > I seem to recall another annoying knot: as you can't set any custom<br>
>> > headers on a preflight request itself in most browsers (any?),<br>
>> > reaching the correct CORS policy is impossible when putting the<br>
>> > X-API-Key in the header. This probably explains why people like Google<br>
>> > require it to be a query parameter.<br>
>> ><br>
>> > Therefore, unless we encoded that information in the URL itself (seems<br>
>> > a bad idea) I think that we can provide full functionality in all<br>
>> > circumstances.<br>
>> ><br>
>> > Unless someone else thinks I'm wrong? Happy to hear alternative<br>
>> > theories.<br>
>> ><br>
>> > On 2 October 2017 at 19:07, Celso Agra <<a href="mailto:celso.agra@gmail.com">celso.agra@gmail.com</a>> wrote:<br>
>> >> I attached an image. Also I added different kinds of headers, just to<br>
>> >> pass<br>
>> >> in case of "Camel Case" validation<br>
>> >> Unfortunately the CORS validation still occurs when I use the plugin...<br>
>> >><br>
>> >> 2017-10-02 15:00 GMT-03:00 Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>>:<br>
>> >>><br>
>> >>> This is from memory, but no, I don't think so: the API key is needed<br>
>> >>> before the correct policy chain (including CORS policy) can be<br>
>> >>> resolved.<br>
>> >>><br>
>> >>> The CORS protocol, when using a custom header, requires a preflight<br>
>> >>> request, however the preflight does not allow any custom headers to be<br>
>> >>> set, so we can't currently resolve the correct policy chain.<br>
>> >>><br>
>> >>> We could think about specifically making X-API-Key available for<br>
>> >>> preflight as I think that should always be okay, but I'll have to<br>
>> >>> investigate whether there are any downsides.<br>
>> >>><br>
>> >>> Of course, we could continue saying to use a query param in that<br>
>> >>> scenario!<br>
>> >>><br>
>> >>> On 2 October 2017 at 18:37, Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a>><br>
>> >>> wrote:<br>
>> >>> > Just to be clear - if X-API-Key is added as an allowed CORS header<br>
>> >>> > in<br>
>> >>> > the<br>
>> >>> > CORS plugin configuration, does that solve the issue?<br>
>> >>> ><br>
>> >>> > -Eric<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On Mon, Oct 2, 2017 at 1:17 PM, Celso Agra <<a href="mailto:celso.agra@gmail.com">celso.agra@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> So, there is no prob to pass as query param!<br>
>> >>> >><br>
>> >>> >> Thanks Marc<br>
>> >>> >><br>
>> >>> >> Best Regards,<br>
>> >>> >><br>
>> >>> >> Celso Agra<br>
>> >>> >><br>
>> >>> >> 2017-10-02 13:49 GMT-03:00 Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>>:<br>
>> >>> >>><br>
>> >>> >>> Hi Celso,<br>
>> >>> >>><br>
>> >>> >>> The query string is encrypted with SSL/TLS.<br>
>> >>> >>><br>
>> >>> >>> Regards,<br>
>> >>> >>> Marc<br>
>> >>> >>><br>
>> >>> >>> On 2 October 2017 at 17:40, Celso Agra <<a href="mailto:celso.agra@gmail.com">celso.agra@gmail.com</a>><br>
>> >>> >>> wrote:<br>
>> >>> >>>><br>
>> >>> >>>> Yeah! It is! My concern is because I'm passing the apiKey as a<br>
>> >>> >>>> query<br>
>> >>> >>>> param.<br>
>> >>> >>>><br>
>> >>> >>>> I don't know if requests works like this in ssl requests, but I<br>
>> >>> >>>> believe<br>
>> >>> >>>> that query params can be viewed if you have a sniffer, unlike<br>
>> >>> >>>> header<br>
>> >>> >>>> params.<br>
>> >>> >>>><br>
>> >>> >>>> So, I'm probably have to allow X-API-Key header in Apiman<br>
>> >>> >>>> requests.<br>
>> >>> >>>> Would be possible to add this feature in a plugin or maybe in the<br>
>> >>> >>>> Apiman?<br>
>> >>> >>>> I'll take a look in some classes to know how to do that.<br>
>> >>> >>>><br>
>> >>> >>>> I'd like to know if it is a feature that will contribute with the<br>
>> >>> >>>> project.<br>
>> >>> >>>><br>
>> >>> >>>> Thanks for your answer Marc.<br>
>> >>> >>>><br>
>> >>> >>>> Best Regards,<br>
>> >>> >>>><br>
>> >>> >>>> Celso Agra<br>
>> >>> >>>><br>
>> >>> >>>><br>
>> >>> >>>> 2017-10-02 9:18 GMT-03:00 Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>>:<br>
>> >>> >>>>><br>
>> >>> >>>>> If I understand your questions correctly: by default CORS does<br>
>> >>> >>>>> not<br>
>> >>> >>>>> allow any custom headers to be sent in the request. This means<br>
>> >>> >>>>> that<br>
>> >>> >>>>> Apiman<br>
>> >>> >>>>> does not receive the X-API-Key header and necessarily can't<br>
>> >>> >>>>> figure<br>
>> >>> >>>>> out how<br>
>> >>> >>>>> to route the request. The same CORS restriction does not exist<br>
>> >>> >>>>> with<br>
>> >>> >>>>> query<br>
>> >>> >>>>> parameters so if you provide it with the query param you'll be<br>
>> >>> >>>>> okay.<br>
>> >>> >>>>><br>
>> >>> >>>>> Perhaps a (partial) solution to some of these kinds of CORS<br>
>> >>> >>>>> issues<br>
>> >>> >>>>> is<br>
>> >>> >>>>> for Apiman to always indicate that the X-API-Key header is<br>
>> >>> >>>>> allowed.<br>
>> >>> >>>>><br>
>> >>> >>>>> Regards,<br>
>> >>> >>>>> Marc<br>
>> >>> >>>>><br>
>> >>> >>>>> On 27 September 2017 at 05:35, Celso Agra <<a href="mailto:celso.agra@gmail.com">celso.agra@gmail.com</a>><br>
>> >>> >>>>> wrote:<br>
>> >>> >>>>>><br>
>> >>> >>>>>> Hi all,<br>
>> >>> >>>>>><br>
>> >>> >>>>>> I got some errors with CORS plugin when I try to use my API<br>
>> >>> >>>>>> with a<br>
>> >>> >>>>>> contract.<br>
>> >>> >>>>>><br>
>> >>> >>>>>> So, I consume my API passing info through header, such as:<br>
>> >>> >>>>>> Authorization, Content-Type, and X-API-Key.<br>
>> >>> >>>>>> I'm talking about a javascript application. So, CORS is a<br>
>> >>> >>>>>> problem<br>
>> >>> >>>>>> for<br>
>> >>> >>>>>> that language.<br>
>> >>> >>>>>><br>
>> >>> >>>>>> When I configure my contract to allow Cross-Origin, the error<br>
>> >>> >>>>>> still<br>
>> >>> >>>>>> there, but if I put my X-API-Key, as a query parameter, the<br>
>> >>> >>>>>> CORS<br>
>> >>> >>>>>> works fine.<br>
>> >>> >>>>>> Does anyone could help me to understand that?<br>
>> >>> >>>>>><br>
>> >>> >>>>>> I'm concerned to pass my contract as a query parameter. It<br>
>> >>> >>>>>> should<br>
>> >>> >>>>>> be<br>
>> >>> >>>>>> on Header of my Http Request.<br>
>> >>> >>>>>> Please, help me to understand if it is a behaviour of the<br>
>> >>> >>>>>> application<br>
>> >>> >>>>>> and how can I solve this without use query param.<br>
>> >>> >>>>>><br>
>> >>> >>>>>> Best Regards,<br>
>> >>> >>>>>><br>
>> >>> >>>>>> --<br>
>> >>> >>>>>> ---<br>
>> >>> >>>>>> Celso Agra<br>
>> >>> >>>>>><br>
>> >>> >>>>>> ______________________________<wbr>_________________<br>
>> >>> >>>>>> Apiman-user mailing list<br>
>> >>> >>>>>> <a href="mailto:Apiman-user@lists.jboss.org">Apiman-user@lists.jboss.org</a><br>
>> >>> >>>>>> <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/apiman-user</a><br>
>> >>> >>>>>><br>
>> >>> >>>>><br>
>> >>> >>>><br>
>> >>> >>>><br>
>> >>> >>>><br>
>> >>> >>>> --<br>
>> >>> >>>> ---<br>
>> >>> >>>> Celso Agra<br>
>> >>> >>><br>
>> >>> >>><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> --<br>
>> >>> >> ---<br>
>> >>> >> Celso Agra<br>
>> >>> >><br>
>> >>> >> ______________________________<wbr>_________________<br>
>> >>> >> Apiman-user mailing list<br>
>> >>> >> <a href="mailto:Apiman-user@lists.jboss.org">Apiman-user@lists.jboss.org</a><br>
>> >>> >> <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/apiman-user</a><br>
>> >>> >><br>
>> >>> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> ---<br>
>> >> Celso Agra<br>
><br>
><br>
><br>
><br>
> --<br>
> ---<br>
> Celso Agra<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-family:'Times New Roman';font-size:16px">---<br><b>Celso Agra</b></span></div></div></div></div></div>
</div>