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

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