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

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