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