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@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@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@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@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@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@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@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ---
>>>> Celso Agra
>>>
>>>
>>
>>
>>
>> --
>> ---
>> Celso Agra
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>