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

[Marc Savy]

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 at redhat.com> 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 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