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> 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> 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>:
>>
>> 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> 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>:
>>>>
>>>> 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>
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
>