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

[Marc Savy]

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 at gmail.com> 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 at redhat.com>:
>>
>> 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 at redhat.com>
>> 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 at gmail.com> 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 at redhat.com>:
>> >>>
>> >>> Hi Celso,
>> >>>
>> >>> The query string is encrypted with SSL/TLS.
>> >>>
>> >>> Regards,
>> >>> Marc
>> >>>
>> >>> On 2 October 2017 at 17:40, Celso Agra <celso.agra at gmail.com> 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 at redhat.com>:
>> >>>>>
>> >>>>> 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 at gmail.com>
>> >>>>> 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 at lists.jboss.org
>> >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> ---
>> >>>> Celso Agra
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> ---
>> >> Celso Agra
>> >>
>> >> _______________________________________________
>> >> Apiman-user mailing list
>> >> Apiman-user at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>
>> >
>
>
>
>
> --
> ---
> Celso Agra