Re: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header?

I understand! I got this conflict because part of my application is made in angular4. I'm using apikey as a query param, but this was a question to me "is this right put apikey as query param?" I believe there is no problem leave this as query param, since url is also encrypted. Thanks for your attention Eric and Marc! 2017-10-02 15:22 GMT-03:00 Marc Savy <marc.savy(a)redhat.com&gt;: > > Correction: > > I think that we can provide full functionality in all > circumstances. > > I think that we *cannot* provide full functionality in all > circumstances. > > On 2 October 2017 at 19:21, Marc Savy <marc.savy(a)redhat.com&gt; wrote: > > I seem to recall another annoying knot: as you can't set any custom > > headers on a preflight request itself in most browsers (any?), > > reaching the correct CORS policy is impossible when putting the > > X-API-Key in the header. This probably explains why people like Google > > require it to be a query parameter. > > > > Therefore, unless we encoded that information in the URL itself (seems > > a bad idea) I think that we can provide full functionality in all > > circumstances. > > > > Unless someone else thinks I'm wrong? Happy to hear alternative > > theories. > > > > On 2 October 2017 at 19:07, Celso Agra <celso.agra(a)gmail.com&gt; wrote: > >> I attached an image. Also I added different kinds of headers, just to > >> pass > >> in case of "Camel Case" validation > >> Unfortunately the CORS validation still occurs when I use the plugin... > >> > >> 2017-10-02 15:00 GMT-03:00 Marc Savy <marc.savy(a)redhat.com&gt;: > >>> > >>> This is from memory, but no, I don't think so: the API key is needed > >>> before the correct policy chain (including CORS policy) can be > >>> resolved. > >>> > >>> The CORS protocol, when using a custom header, requires a preflight > >>> request, however the preflight does not allow any custom headers to be > >>> set, so we can't currently resolve the correct policy chain. > >>> > >>> We could think about specifically making X-API-Key available for > >>> preflight as I think that should always be okay, but I'll have to > >>> investigate whether there are any downsides. > >>> > >>> Of course, we could continue saying to use a query param in that > >>> scenario! > >>> > >>> On 2 October 2017 at 18:37, Eric Wittmann <eric.wittmann(a)redhat.com&gt; > >>> wrote: > >>> > Just to be clear - if X-API-Key is added as an allowed CORS header > >>> > in > >>> > the > >>> > CORS plugin configuration, does that solve the issue? > >>> > > >>> > -Eric > >>> > > >>> > > >>> > On Mon, Oct 2, 2017 at 1:17 PM, Celso Agra <celso.agra(a)gmail.com&gt; > >>> > wrote: > >>> >> > >>> >> So, there is no prob to pass as query param! > >>> >> > >>> >> Thanks Marc > >>> >> > >>> >> Best Regards, > >>> >> > >>> >> Celso Agra > >>> >> > >>> >> 2017-10-02 13:49 GMT-03:00 Marc Savy <marc.savy(a)redhat.com&gt;: > >>> >>> > >>> >>> Hi Celso, > >>> >>> > >>> >>> The query string is encrypted with SSL/TLS. > >>> >>> > >>> >>> Regards, > >>> >>> Marc > >>> >>> > >>> >>> On 2 October 2017 at 17:40, Celso Agra <celso.agra(a)gmail.com&gt; > >>> >>> wrote: > >>> >>>> > >>> >>>> Yeah! It is! My concern is because I'm passing the apiKey as a > >>> >>>> query > >>> >>>> param. > >>> >>>> > >>> >>>> I don't know if requests works like this in ssl requests, but I > >>> >>>> believe > >>> >>>> that query params can be viewed if you have a sniffer, unlike > >>> >>>> header > >>> >>>> params. > >>> >>>> > >>> >>>> So, I'm probably have to allow X-API-Key header in Apiman > >>> >>>> requests. > >>> >>>> Would be possible to add this feature in a plugin or maybe in the > >>> >>>> Apiman? > >>> >>>> I'll take a look in some classes to know how to do that. > >>> >>>> > >>> >>>> I'd like to know if it is a feature that will contribute with the > >>> >>>> project. > >>> >>>> > >>> >>>> Thanks for your answer Marc. > >>> >>>> > >>> >>>> Best Regards, > >>> >>>> > >>> >>>> Celso Agra > >>> >>>> > >>> >>>> > >>> >>>> 2017-10-02 9:18 GMT-03:00 Marc Savy <marc.savy(a)redhat.com&gt;: > >>> >>>>> > >>> >>>>> If I understand your questions correctly: by default CORS does > >>> >>>>> not > >>> >>>>> allow any custom headers to be sent in the request. This means > >>> >>>>> that > >>> >>>>> Apiman > >>> >>>>> does not receive the X-API-Key header and necessarily can't > >>> >>>>> figure > >>> >>>>> out how > >>> >>>>> to route the request. The same CORS restriction does not exist > >>> >>>>> with > >>> >>>>> query > >>> >>>>> parameters so if you provide it with the query param you'll be > >>> >>>>> okay. > >>> >>>>> > >>> >>>>> Perhaps a (partial) solution to some of these kinds of CORS > >>> >>>>> issues > >>> >>>>> is > >>> >>>>> for Apiman to always indicate that the X-API-Key header is > >>> >>>>> allowed. > >>> >>>>> > >>> >>>>> Regards, > >>> >>>>> Marc > >>> >>>>> > >>> >>>>> On 27 September 2017 at 05:35, Celso Agra <celso.agra(a)gmail.com&gt; > >>> >>>>> wrote: > >>> >>>>>> > >>> >>>>>> Hi all, > >>> >>>>>> > >>> >>>>>> I got some errors with CORS plugin when I try to use my API > >>> >>>>>> with a > >>> >>>>>> contract. > >>> >>>>>> > >>> >>>>>> So, I consume my API passing info through header, such as: > >>> >>>>>> Authorization, Content-Type, and X-API-Key. > >>> >>>>>> I'm talking about a javascript application. So, CORS is a > >>> >>>>>> problem > >>> >>>>>> for > >>> >>>>>> that language. > >>> >>>>>> > >>> >>>>>> When I configure my contract to allow Cross-Origin, the error > >>> >>>>>> still > >>> >>>>>> there, but if I put my X-API-Key, as a query parameter, the > >>> >>>>>> CORS > >>> >>>>>> works fine. > >>> >>>>>> Does anyone could help me to understand that? > >>> >>>>>> > >>> >>>>>> I'm concerned to pass my contract as a query parameter. It > >>> >>>>>> should > >>> >>>>>> be > >>> >>>>>> on Header of my Http Request. > >>> >>>>>> Please, help me to understand if it is a behaviour of the > >>> >>>>>> application > >>> >>>>>> and how can I solve this without use query param. > >>> >>>>>> > >>> >>>>>> Best Regards, > >>> >>>>>> > >>> >>>>>> -- > >>> >>>>>> --- > >>> >>>>>> Celso Agra > >>> >>>>>> > >>> >>>>>> _______________________________________________ > >>> >>>>>> Apiman-user mailing list > >>> >>>>>> Apiman-user(a)lists.jboss.org > >>> >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>> >>>>>> > >>> >>>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> -- > >>> >>>> --- > >>> >>>> Celso Agra > >>> >>> > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> --- > >>> >> Celso Agra > >>> >> > >>> >> _______________________________________________ > >>> >> Apiman-user mailing list > >>> >> Apiman-user(a)lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/apiman-user > >>> >> > >>> > > >> > >> > >> > >> > >> -- > >> --- > >> Celso Agra -- --- Celso Agra