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&gt; 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 > >

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&gt; 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&gt;: > >> 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&gt; 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* >

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&gt; 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&gt;: >> >> 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&gt; 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&gt;: >>>> >>>> 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&gt; 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 >

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&gt;: > > 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&gt; > 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&gt; 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&gt;: > >>> > >>> 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&gt; 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&gt;: > >>>>> > >>>>> 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&gt; > >>>>> 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

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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&gt;: >>> >>> 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&gt; >>> 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&gt; 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&gt;: >>> >>> >>> >>> 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&gt; 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&gt;: >>> >>>>> >>> >>>>> 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&gt; >>> >>>>> 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

This is a good area of discussion. There are some caveats to the query parameters approach. Query params are sometimes stored in logs and other areas where you wouldn't want highly sensitive data being kept. I think in the Apiman API Key case it should be okay, but it depends on your use case: - The API Key is only to provide correlation between an inbound request and an Apiman Client; it doesn't really provide security. For example, you would generally still need to do OAuth2, JWT, BASIC or some other security mechanism over the top if you want "real" auth and authz. - The Apiman Gateway strips out the apikey query parameter (i.e. it doesn't get passed to the backend). However, if you terminate SSL before the Apiman Gateway then it might have a chance to be stored in some logs elsewhere. For example, using my echo service (just responds back with what it receives): }[msavy@mmbp apiman](list-prototype)$ curl -k 'https://localhost:8443/test/froofroo/9003?apikey=7ab94cd5- 6d31-4ed0-ba8a-607b2cbe0bc9&another=thing' { "method" : "GET", "resource" : "/a/b/c/?another=thing", (1) "uri" : "/a/b/c/", "headers" : { "Transfer-Encoding" : "chunked", "Accept" : "*/*", "User-Agent" : "curl/7.54.0", "Host" : "localhost:9999" }, "bodyLength" : null, "bodySha1" : null, "counter" : 6 (1) Notice that the apikey query parameter has not appeared in the echoed response As a fairly rough solution, perhaps we could allow people to additionally set a global CORS config on the Apiman Gateway (e.g. in your case where you control the entire gateway this could be a useful 'base case'). On 2 October 2017 at 19:52, Celso Agra <celso.agra(a)gmail.com&gt; wrote: > 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(a)redhat.com&gt;: >> >> 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(a)redhat.com&gt; 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(a)gmail.com&gt; 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&gt;: >> >>> >> >>> 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&gt; >> >>> > 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&gt;: >> >>> >>> >> >>> >>> 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&gt; >> >>> >>> 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&gt;: >> >>> >>>>> >> >>> >>>>> 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&gt; >> >>> >>>>> 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 > > > > > -- > --- > Celso Agra