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

[Celso Agra]

I understand!

I got this conflict because part of my application is made in angular4.
I'm using apikey as a query param, but this was a question to me "is this
right put apikey as query param?"

I believe there is no problem leave this as query param, since url is also
encrypted.

Thanks for your attention Eric and Marc!


2017-10-02 15:22 GMT-03:00 Marc Savy <marc.savy at redhat.com>:

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



-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/92050cea/attachment-0001.html