From marc.savy at redhat.com Mon Oct 2 08:18:35 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 13:18:35 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/662df466/attachment.html From celso.agra at gmail.com Mon Oct 2 12:40:54 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 2 Oct 2017 13:40:54 -0300 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 : > 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 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/c3d9caae/attachment.html From marc.savy at redhat.com Mon Oct 2 12:49:35 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 17:49:35 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: Hi Celso, The query string is encrypted with SSL/TLS. Regards, Marc On 2 October 2017 at 17:40, Celso Agra 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 : > >> 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 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* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/a5eb72d4/attachment.html From celso.agra at gmail.com Mon Oct 2 13:17:41 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 2 Oct 2017 14:17:41 -0300 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 : > Hi Celso, > > The query string is encrypted with SSL/TLS. > > Regards, > Marc > > On 2 October 2017 at 17:40, Celso Agra 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 : >> >>> 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 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/e12d80d6/attachment-0001.html From eric.wittmann at redhat.com Mon Oct 2 13:37:28 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 2 Oct 2017 13:37:28 -0400 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 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 : > >> Hi Celso, >> >> The query string is encrypted with SSL/TLS. >> >> Regards, >> Marc >> >> On 2 October 2017 at 17:40, Celso Agra 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 : >>> >>>> 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/73029b7b/attachment.html From marc.savy at redhat.com Mon Oct 2 14:00:49 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 19:00:49 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 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 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 : >>> >>> Hi Celso, >>> >>> The query string is encrypted with SSL/TLS. >>> >>> Regards, >>> Marc >>> >>> On 2 October 2017 at 17:40, Celso Agra 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 : >>>>> >>>>> 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 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 >> > From celso.agra at gmail.com Mon Oct 2 14:07:48 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 2 Oct 2017 15:07:48 -0300 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 : > 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 > 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 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 : > >>> > >>> Hi Celso, > >>> > >>> The query string is encrypted with SSL/TLS. > >>> > >>> Regards, > >>> Marc > >>> > >>> On 2 October 2017 at 17:40, Celso Agra 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 : > >>>>> > >>>>> 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 > 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/71b4ed01/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman_cors_verify.png Type: image/png Size: 25258 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/71b4ed01/attachment-0001.png From marc.savy at redhat.com Mon Oct 2 14:21:05 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 19:21:05 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 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 : >> >> 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 >> 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 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 : >> >>> >> >>> Hi Celso, >> >>> >> >>> The query string is encrypted with SSL/TLS. >> >>> >> >>> Regards, >> >>> Marc >> >>> >> >>> On 2 October 2017 at 17:40, Celso Agra 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 : >> >>>>> >> >>>>> 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 >> >>>>> 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 From marc.savy at redhat.com Mon Oct 2 14:22:14 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 19:22:14 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 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 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 : >>> >>> 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 >>> 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 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 : >>> >>> >>> >>> Hi Celso, >>> >>> >>> >>> The query string is encrypted with SSL/TLS. >>> >>> >>> >>> Regards, >>> >>> Marc >>> >>> >>> >>> On 2 October 2017 at 17:40, Celso Agra 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 : >>> >>>>> >>> >>>>> 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 >>> >>>>> 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 From celso.agra at gmail.com Mon Oct 2 14:52:29 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 2 Oct 2017 15:52:29 -0300 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 : > 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 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 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 : > >>> > >>> 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 > >>> 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 > 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 : > >>> >>> > >>> >>> Hi Celso, > >>> >>> > >>> >>> The query string is encrypted with SSL/TLS. > >>> >>> > >>> >>> Regards, > >>> >>> Marc > >>> >>> > >>> >>> On 2 October 2017 at 17:40, Celso Agra > 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 : > >>> >>>>> > >>> >>>>> 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 > >>> >>>>> 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 From marc.savy at redhat.com Mon Oct 2 16:40:28 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Oct 2017 21:40:28 +0100 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: 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 at 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 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 : >> >> 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 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 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 : >> >>> >> >>> 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 >> >>> 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 >> >>> > 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 : >> >>> >>> >> >>> >>> Hi Celso, >> >>> >>> >> >>> >>> The query string is encrypted with SSL/TLS. >> >>> >>> >> >>> >>> Regards, >> >>> >>> Marc >> >>> >>> >> >>> >>> On 2 October 2017 at 17:40, Celso Agra >> >>> >>> 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 : >> >>> >>>>> >> >>> >>>>> 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 >> >>> >>>>> 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 From celso.agra at gmail.com Mon Oct 2 20:44:29 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 2 Oct 2017 21:44:29 -0300 Subject: [Apiman-user] How to solve the conflict about CORS and the X-API-Key in header? In-Reply-To: References: Message-ID: Great! Global CORS could be awesome and useful! In general I'm using API Key to use some security policies. My policies involves IP address white list, oauth integration with keycloak, and roles verification. Also, I used a validation about the number of requests filtered by IP Address to avoid DDoS or web crawlers. So, there is some difficulties... When I'm using javascript and mobile apps, I don't know if would be possible to use the white list. I've never tried to test that. but, using integration with keycloak gives me a security level, so that's ok to me! Thanks for your answer! Best Regards, Celso Agra 2017-10-02 17:40 GMT-03:00 Marc Savy : > 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 at 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 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 : > >> > >> 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 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 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 : > >> >>> > >> >>> 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 > > >> >>> 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 > >> >>> > 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 : > >> >>> >>> > >> >>> >>> Hi Celso, > >> >>> >>> > >> >>> >>> The query string is encrypted with SSL/TLS. > >> >>> >>> > >> >>> >>> Regards, > >> >>> >>> Marc > >> >>> >>> > >> >>> >>> On 2 October 2017 at 17:40, Celso Agra > >> >>> >>> 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 : > >> >>> >>>>> > >> >>> >>>>> 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 > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/e8e06535/attachment-0001.html From jorge at larix.cl Wed Oct 4 22:24:38 2017 From: jorge at larix.cl (Jorge Riquelme) Date: Wed, 4 Oct 2017 23:24:38 -0300 Subject: [Apiman-user] Bind Vert.x Gateway to IP Message-ID: Hi, I couldn't find how to bind Vert.x Gateway to a specific IP (using the conf-es.json file, or some parameter like -b=x.x.x.x). Any help would be appreciated :) Best regards, Jorge Riquelme -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171004/5e9b1b82/attachment.html From eric.wittmann at redhat.com Thu Oct 5 07:22:34 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 5 Oct 2017 07:22:34 -0400 Subject: [Apiman-user] Bind Vert.x Gateway to IP In-Reply-To: References: Message-ID: Currently I believe the vert.x gateway listens on all interfaces (0.0.0.0). For example: https://github.com/apiman/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpGatewayVerticle.java#L49-L51 If you need a way to ONLY listen on a particular host, then I think that needs to be a code change. If that's the case, submit a ticket: https://issues.jboss.org/projects/APIMAN/issues Or submit a pull request! It's a pretty simple change. :) -Eric On Wed, Oct 4, 2017 at 10:24 PM, Jorge Riquelme wrote: > Hi, > > I couldn't find how to bind Vert.x Gateway to a specific IP (using the > conf-es.json file, or some parameter like -b=x.x.x.x). > > Any help would be appreciated :) > > Best regards, > Jorge Riquelme > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171005/1b8c0cbb/attachment.html From jorge at larix.cl Thu Oct 5 09:32:26 2017 From: jorge at larix.cl (Jorge Riquelme) Date: Thu, 5 Oct 2017 10:32:26 -0300 Subject: [Apiman-user] Bind Vert.x Gateway to IP In-Reply-To: References: Message-ID: Hi Eric, Thank you for the clarification. In fact, I made a change there yesterday to get the Gateway running, but I wasn't sure if some alternative was available. I created a Jira issue (https://issues.jboss.org/browse/APIMAN-1292) and a pull request (https://github.com/apiman/apiman/pull/627). Best regards, Jorge Riquelme *Jorge Riquelme Santana* *Co-founder & CTO*, Larix mobile: (+56 9) 66594454 <%28%2B56%209%29%2062481315> web: www.larix.cl On Thu, Oct 5, 2017 at 8:22 AM, Eric Wittmann wrote: > Currently I believe the vert.x gateway listens on all interfaces > (0.0.0.0). For example: > > https://github.com/apiman/apiman/blob/master/gateway/ > platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/ > platforms/vertx3/verticles/HttpGatewayVerticle.java#L49-L51 > > If you need a way to ONLY listen on a particular host, then I think that > needs to be a code change. If that's the case, submit a ticket: > > https://issues.jboss.org/projects/APIMAN/issues > > Or submit a pull request! It's a pretty simple change. :) > > -Eric > > > On Wed, Oct 4, 2017 at 10:24 PM, Jorge Riquelme wrote: > >> Hi, >> >> I couldn't find how to bind Vert.x Gateway to a specific IP (using the >> conf-es.json file, or some parameter like -b=x.x.x.x). >> >> Any help would be appreciated :) >> >> Best regards, >> Jorge Riquelme >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171005/d8cda0e8/attachment.html From eric.wittmann at redhat.com Thu Oct 5 10:13:48 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 5 Oct 2017 10:13:48 -0400 Subject: [Apiman-user] Bind Vert.x Gateway to IP In-Reply-To: References: Message-ID: Awesome! We'll get it merged in asap. On Thu, Oct 5, 2017 at 9:32 AM, Jorge Riquelme wrote: > Hi Eric, > > Thank you for the clarification. In fact, I made a change there yesterday > to get the Gateway running, but I wasn't sure if some alternative was > available. > > I created a Jira issue (https://issues.jboss.org/browse/APIMAN-1292) and > a pull request (https://github.com/apiman/apiman/pull/627). > > Best regards, > Jorge Riquelme > > *Jorge Riquelme Santana* > *Co-founder & CTO*, Larix > mobile: (+56 9) 66594454 <%28%2B56%209%29%2062481315> > web: www.larix.cl > > On Thu, Oct 5, 2017 at 8:22 AM, Eric Wittmann > wrote: > >> Currently I believe the vert.x gateway listens on all interfaces >> (0.0.0.0). For example: >> >> https://github.com/apiman/apiman/blob/master/gateway/platfor >> ms/vertx3/vertx3/src/main/java/io/apiman/gateway/platfor >> ms/vertx3/verticles/HttpGatewayVerticle.java#L49-L51 >> >> If you need a way to ONLY listen on a particular host, then I think that >> needs to be a code change. If that's the case, submit a ticket: >> >> https://issues.jboss.org/projects/APIMAN/issues >> >> Or submit a pull request! It's a pretty simple change. :) >> >> -Eric >> >> >> On Wed, Oct 4, 2017 at 10:24 PM, Jorge Riquelme wrote: >> >>> Hi, >>> >>> I couldn't find how to bind Vert.x Gateway to a specific IP (using the >>> conf-es.json file, or some parameter like -b=x.x.x.x). >>> >>> Any help would be appreciated :) >>> >>> Best regards, >>> Jorge Riquelme >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171005/886aa2d2/attachment-0001.html From ashish.patel at futuregroup.in Wed Oct 11 04:53:30 2017 From: ashish.patel at futuregroup.in (Ashish Patel) Date: Wed, 11 Oct 2017 08:53:30 +0000 Subject: [Apiman-user] Custom reports from ES Message-ID: <73bc2b0e44f94f3e9afe97375a32ab0a@futuregroup.in> Hi, We are using APIMan (1.2.7) in production and can see default API Metrics from APIMan Manager instance. It gives last 30 days/7 days usage. However, we would like to fetch custom reports like 1. Max/Avg no of requests per day per API 2. Max/Avg. response time per API 3. Total no. of APIs being used in last X days (across different organization). ..... etc. Can we plug Kibana on top of ES and fetch such reports ? In case if we want to shoot direct ES command , any help in ES queries to retrieve reports such as above ? Any other help to achieve above will be highly appreciated. Thanks & Regards, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171011/c4350c28/attachment.html From eric.wittmann at redhat.com Wed Oct 11 08:16:28 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 11 Oct 2017 08:16:28 -0400 Subject: [Apiman-user] Custom reports from ES In-Reply-To: <73bc2b0e44f94f3e9afe97375a32ab0a@futuregroup.in> References: <73bc2b0e44f94f3e9afe97375a32ab0a@futuregroup.in> Message-ID: You should definitely be able to use Kibana for more custom and interesting data analysis of the metrics data. Examples of the existing ES queries that produce the data shown in the Apiman UI can be found here: https://github.com/apiman/apiman/blob/master/manager/api/es/src/main/java/io/apiman/manager/api/es/ESMetricsAccessor.java And here is where you can find all of the properties stored in ES for each metric: https://github.com/apiman/apiman/blob/master/gateway/engine/core/src/main/java/io/apiman/gateway/engine/metrics/RequestMetric.java -Eric On Wed, Oct 11, 2017 at 4:53 AM, Ashish Patel wrote: > Hi, > > > > We are using APIMan (1.2.7) in production and can see default API Metrics > from APIMan Manager instance. It gives last 30 days/7 days usage. However, > we would like to fetch custom reports like > > > > 1. Max/Avg no of requests per day per API > > 2. Max/Avg. response time per API > > 3. Total no. of APIs being used in last X days (across different > organization). > > ..... etc. > > > > Can we plug Kibana on top of ES and fetch such reports ? > > In case if we want to shoot direct ES command , any help in ES queries to > retrieve reports such as above ? > > Any other help to achieve above will be highly appreciated. > > > > Thanks & Regards, > > Ashish > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171011/edce1058/attachment.html From marc.savy at redhat.com Wed Oct 11 11:55:03 2017 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 11 Oct 2017 17:55:03 +0200 Subject: [Apiman-user] Custom reports from ES In-Reply-To: References: <73bc2b0e44f94f3e9afe97375a32ab0a@futuregroup.in> Message-ID: +1 and, Asish, please think about sharing your queries and setup with the community so everyone can benefit from your expierence. On 11 October 2017 at 14:16, Eric Wittmann wrote: > You should definitely be able to use Kibana for more custom and > interesting data analysis of the metrics data. > > Examples of the existing ES queries that produce the data shown in the > Apiman UI can be found here: > > https://github.com/apiman/apiman/blob/master/manager/ > api/es/src/main/java/io/apiman/manager/api/es/ESMetricsAccessor.java > > And here is where you can find all of the properties stored in ES for each > metric: > > https://github.com/apiman/apiman/blob/master/gateway/ > engine/core/src/main/java/io/apiman/gateway/engine/metrics/ > RequestMetric.java > > -Eric > > On Wed, Oct 11, 2017 at 4:53 AM, Ashish Patel > wrote: > >> Hi, >> >> >> >> We are using APIMan (1.2.7) in production and can see default API Metrics >> from APIMan Manager instance. It gives last 30 days/7 days usage. However, >> we would like to fetch custom reports like >> >> >> >> 1. Max/Avg no of requests per day per API >> >> 2. Max/Avg. response time per API >> >> 3. Total no. of APIs being used in last X days (across different >> organization). >> >> ..... etc. >> >> >> >> Can we plug Kibana on top of ES and fetch such reports ? >> >> In case if we want to shoot direct ES command , any help in ES queries to >> retrieve reports such as above ? >> >> Any other help to achieve above will be highly appreciated. >> >> >> >> Thanks & Regards, >> >> Ashish >> >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171011/c87bd5e2/attachment.html From ashish.patel at futuregroup.in Thu Oct 12 00:39:45 2017 From: ashish.patel at futuregroup.in (Ashish Patel) Date: Thu, 12 Oct 2017 04:39:45 +0000 Subject: [Apiman-user] Custom reports from ES In-Reply-To: References: <73bc2b0e44f94f3e9afe97375a32ab0a@futuregroup.in> Message-ID: Definitely Marc. We have holidays starting this weekend In India and shall be taking up below after I come back. From: Marc Savy [mailto:marc.savy at redhat.com] Sent: Wednesday, October 11, 2017 21:25 To: Eric Wittmann Cc: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Custom reports from ES +1 and, Asish, please think about sharing your queries and setup with the community so everyone can benefit from your expierence. On 11 October 2017 at 14:16, Eric Wittmann > wrote: You should definitely be able to use Kibana for more custom and interesting data analysis of the metrics data. Examples of the existing ES queries that produce the data shown in the Apiman UI can be found here: https://github.com/apiman/apiman/blob/master/manager/api/es/src/main/java/io/apiman/manager/api/es/ESMetricsAccessor.java And here is where you can find all of the properties stored in ES for each metric: https://github.com/apiman/apiman/blob/master/gateway/engine/core/src/main/java/io/apiman/gateway/engine/metrics/RequestMetric.java -Eric On Wed, Oct 11, 2017 at 4:53 AM, Ashish Patel > wrote: Hi, We are using APIMan (1.2.7) in production and can see default API Metrics from APIMan Manager instance. It gives last 30 days/7 days usage. However, we would like to fetch custom reports like 1. Max/Avg no of requests per day per API 2. Max/Avg. response time per API 3. Total no. of APIs being used in last X days (across different organization). ..... etc. Can we plug Kibana on top of ES and fetch such reports ? In case if we want to shoot direct ES command , any help in ES queries to retrieve reports such as above ? Any other help to achieve above will be highly appreciated. Thanks & Regards, Ashish _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171012/7c260b70/attachment-0001.html From celso.agra at gmail.com Tue Oct 17 10:51:37 2017 From: celso.agra at gmail.com (Celso Agra) Date: Tue, 17 Oct 2017 11:51:37 -0300 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header Message-ID: Hi all, I got an "Internal Server Error" when I send a DELETE request method and there is no Content-Type in header. I'd like to know if this is an expected behavior, or something else should be configured? I'm using Apiman 1.3.0.Final with CORS plugin. PS.: This behavior just occurs when I send a DELETE method request through Apiman without "Content-Type" in header. Here is some examples: > *Example 01 $ curl -X "DELETE" > https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx > **ErrorInternal > Server Error* > > > *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" > https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx > **[ > { "return": "OK" } ]* Best Regards, -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171017/38b5c365/attachment.html From marc.savy at redhat.com Wed Oct 18 02:46:41 2017 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 18 Oct 2017 08:46:41 +0200 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Hi Celso, Are you using Vert.x or Servlet Apiman Gateway? Regards Marc On 17 October 2017 at 16:51, Celso Agra wrote: > Hi all, > > I got an "Internal Server Error" when I send a DELETE request method and > there is no Content-Type in header. I'd like to know if this is an expected > behavior, or something else should be configured? I'm using Apiman > 1.3.0.Final with CORS plugin. > > PS.: This behavior just occurs when I send a DELETE method request through > Apiman without "Content-Type" in header. > > Here is some examples: > > >> *Example 01 $ curl -X "DELETE" >> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >> **ErrorInternal >> Server Error* > > > >> >> >> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >> **[ >> { "return": "OK" } ]* > > > > > Best Regards, > > -- > --- > *Celso Agra* > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/ca9ec37a/attachment.html From celso.agra at gmail.com Wed Oct 18 05:27:46 2017 From: celso.agra at gmail.com (Celso Agra) Date: Wed, 18 Oct 2017 09:27:46 +0000 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Thanks for your reply, Marc! I'm using Servlet Apiman Gateway. Best Regards, Celso Agra Em qua, 18 de out de 2017 ?s 03:47, Marc Savy escreveu: > Hi Celso, > > Are you using Vert.x or Servlet Apiman Gateway? > > Regards > Marc > > On 17 October 2017 at 16:51, Celso Agra wrote: > >> Hi all, >> >> I got an "Internal Server Error" when I send a DELETE request method and >> there is no Content-Type in header. I'd like to know if this is an expected >> behavior, or something else should be configured? I'm using Apiman >> 1.3.0.Final with CORS plugin. >> >> PS.: This behavior just occurs when I send a DELETE method request >> through Apiman without "Content-Type" in header. >> >> Here is some examples: >> >> >>> *Example 01 $ curl -X "DELETE" >>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>> **ErrorInternal >>> Server Error* >> >> >> >>> >>> >>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>> **[ >>> { "return": "OK" } ]* >> >> >> >> >> Best Regards, >> >> -- >> --- >> *Celso Agra* >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/5dbedfd8/attachment.html From eric.wittmann at redhat.com Wed Oct 18 08:22:40 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 18 Oct 2017 08:22:40 -0400 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Are there any errors in the server logs that could help diagnose this issue? On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra wrote: > Hi all, > > I got an "Internal Server Error" when I send a DELETE request method and > there is no Content-Type in header. I'd like to know if this is an expected > behavior, or something else should be configured? I'm using Apiman > 1.3.0.Final with CORS plugin. > > PS.: This behavior just occurs when I send a DELETE method request through > Apiman without "Content-Type" in header. > > Here is some examples: > > >> *Example 01 $ curl -X "DELETE" >> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >> **ErrorInternal >> Server Error* > > > >> >> >> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >> **[ >> { "return": "OK" } ]* > > > > > Best Regards, > > -- > --- > *Celso Agra* > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/873146d5/attachment.html From celso.agra at gmail.com Wed Oct 18 13:23:22 2017 From: celso.agra at gmail.com (Celso Agra) Date: Wed, 18 Oct 2017 14:23:22 -0300 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Hi Eric, I look into "standalone/log/server.log", and I didn't see anything about this. =/ Best Regards, Celso Agra 2017-10-18 9:22 GMT-03:00 Eric Wittmann : > Are there any errors in the server logs that could help diagnose this > issue? > > On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra wrote: > >> Hi all, >> >> I got an "Internal Server Error" when I send a DELETE request method and >> there is no Content-Type in header. I'd like to know if this is an expected >> behavior, or something else should be configured? I'm using Apiman >> 1.3.0.Final with CORS plugin. >> >> PS.: This behavior just occurs when I send a DELETE method request >> through Apiman without "Content-Type" in header. >> >> Here is some examples: >> >> >>> *Example 01 $ curl -X "DELETE" >>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>> **ErrorInternal >>> Server Error* >> >> >> >>> >>> >>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>> **[ >>> { "return": "OK" } ]* >> >> >> >> >> Best Regards, >> >> -- >> --- >> *Celso Agra* >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/1509fac3/attachment-0001.html From eric.wittmann at redhat.com Wed Oct 18 14:21:33 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 18 Oct 2017 14:21:33 -0400 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Is there any chance that the Internal Server Error is coming from the API being proxied? :) -Eric On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra wrote: > Hi Eric, > > I look into "standalone/log/server.log", and I didn't see anything about > this. =/ > > Best Regards, > > Celso Agra > > > 2017-10-18 9:22 GMT-03:00 Eric Wittmann : > >> Are there any errors in the server logs that could help diagnose this >> issue? >> >> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >> wrote: >> >>> Hi all, >>> >>> I got an "Internal Server Error" when I send a DELETE request method and >>> there is no Content-Type in header. I'd like to know if this is an expected >>> behavior, or something else should be configured? I'm using Apiman >>> 1.3.0.Final with CORS plugin. >>> >>> PS.: This behavior just occurs when I send a DELETE method request >>> through Apiman without "Content-Type" in header. >>> >>> Here is some examples: >>> >>> >>>> *Example 01 $ curl -X "DELETE" >>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>> **ErrorInternal >>>> Server Error* >>> >>> >>> >>>> >>>> >>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>> **[ >>>> { "return": "OK" } ]* >>> >>> >>> >>> >>> Best Regards, >>> >>> -- >>> --- >>> *Celso Agra* >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >> > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/e068731f/attachment.html From celso.agra at gmail.com Wed Oct 18 14:31:36 2017 From: celso.agra at gmail.com (Celso Agra) Date: Wed, 18 Oct 2017 15:31:36 -0300 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: I'll try to simulate that with another VM and API. I'll bring results soon as possible! 2017-10-18 15:21 GMT-03:00 Eric Wittmann : > Is there any chance that the Internal Server Error is coming from the API > being proxied? :) > > -Eric > > > On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra wrote: > >> Hi Eric, >> >> I look into "standalone/log/server.log", and I didn't see anything about >> this. =/ >> >> Best Regards, >> >> Celso Agra >> >> >> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >> >>> Are there any errors in the server logs that could help diagnose this >>> issue? >>> >>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>> wrote: >>> >>>> Hi all, >>>> >>>> I got an "Internal Server Error" when I send a DELETE request method >>>> and there is no Content-Type in header. I'd like to know if this is an >>>> expected behavior, or something else should be configured? I'm using Apiman >>>> 1.3.0.Final with CORS plugin. >>>> >>>> PS.: This behavior just occurs when I send a DELETE method request >>>> through Apiman without "Content-Type" in header. >>>> >>>> Here is some examples: >>>> >>>> >>>>> *Example 01 $ curl -X "DELETE" >>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>> **ErrorInternal >>>>> Server Error* >>>> >>>> >>>> >>>>> >>>>> >>>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>> **[ >>>>> { "return": "OK" } ]* >>>> >>>> >>>> >>>> >>>> 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/37fedcb9/attachment.html From eric.wittmann at redhat.com Wed Oct 18 16:25:33 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 18 Oct 2017 16:25:33 -0400 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: What I mean is: what happens if you bypass the apiman gateway and make an identical curl request directly to the back-end API? I'm asking because I'm coming up empty on why an internal server error could happen in the apiman gateway without generating a stack trace in the log. :) -Eric On Wed, Oct 18, 2017 at 2:31 PM, Celso Agra wrote: > I'll try to simulate that with another VM and API. > > I'll bring results soon as possible! > > 2017-10-18 15:21 GMT-03:00 Eric Wittmann : > >> Is there any chance that the Internal Server Error is coming from the API >> being proxied? :) >> >> -Eric >> >> >> On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra wrote: >> >>> Hi Eric, >>> >>> I look into "standalone/log/server.log", and I didn't see anything about >>> this. =/ >>> >>> Best Regards, >>> >>> Celso Agra >>> >>> >>> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >>> >>>> Are there any errors in the server logs that could help diagnose this >>>> issue? >>>> >>>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I got an "Internal Server Error" when I send a DELETE request method >>>>> and there is no Content-Type in header. I'd like to know if this is an >>>>> expected behavior, or something else should be configured? I'm using Apiman >>>>> 1.3.0.Final with CORS plugin. >>>>> >>>>> PS.: This behavior just occurs when I send a DELETE method request >>>>> through Apiman without "Content-Type" in header. >>>>> >>>>> Here is some examples: >>>>> >>>>> >>>>>> *Example 01 $ curl -X "DELETE" >>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>> **ErrorInternal >>>>>> Server Error* >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>> **[ >>>>>> { "return": "OK" } ]* >>>>> >>>>> >>>>> >>>>> >>>>> 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* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/85ccfbce/attachment-0001.html From celso.agra at gmail.com Wed Oct 18 16:33:49 2017 From: celso.agra at gmail.com (Celso Agra) Date: Wed, 18 Oct 2017 17:33:49 -0300 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: The API works fine here! 2017-10-18 17:25 GMT-03:00 Eric Wittmann : > What I mean is: what happens if you bypass the apiman gateway and make an > identical curl request directly to the back-end API? > > I'm asking because I'm coming up empty on why an internal server error > could happen in the apiman gateway without generating a stack trace in the > log. :) > > -Eric > > On Wed, Oct 18, 2017 at 2:31 PM, Celso Agra wrote: > >> I'll try to simulate that with another VM and API. >> >> I'll bring results soon as possible! >> >> 2017-10-18 15:21 GMT-03:00 Eric Wittmann : >> >>> Is there any chance that the Internal Server Error is coming from the >>> API being proxied? :) >>> >>> -Eric >>> >>> >>> On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra >>> wrote: >>> >>>> Hi Eric, >>>> >>>> I look into "standalone/log/server.log", and I didn't see anything >>>> about this. =/ >>>> >>>> Best Regards, >>>> >>>> Celso Agra >>>> >>>> >>>> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >>>> >>>>> Are there any errors in the server logs that could help diagnose this >>>>> issue? >>>>> >>>>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I got an "Internal Server Error" when I send a DELETE request method >>>>>> and there is no Content-Type in header. I'd like to know if this is an >>>>>> expected behavior, or something else should be configured? I'm using Apiman >>>>>> 1.3.0.Final with CORS plugin. >>>>>> >>>>>> PS.: This behavior just occurs when I send a DELETE method request >>>>>> through Apiman without "Content-Type" in header. >>>>>> >>>>>> Here is some examples: >>>>>> >>>>>> >>>>>>> *Example 01 $ curl -X "DELETE" >>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>> **ErrorInternal >>>>>>> Server Error* >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>> **[ >>>>>>> { "return": "OK" } ]* >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/67bb137a/attachment.html From eric.wittmann at redhat.com Wed Oct 18 17:24:57 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 18 Oct 2017 17:24:57 -0400 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: OK thanks. I assumed that was the case but wanted to make sure! :) On Wed, Oct 18, 2017 at 4:33 PM, Celso Agra wrote: > The API works fine here! > > 2017-10-18 17:25 GMT-03:00 Eric Wittmann : > >> What I mean is: what happens if you bypass the apiman gateway and make >> an identical curl request directly to the back-end API? >> >> I'm asking because I'm coming up empty on why an internal server error >> could happen in the apiman gateway without generating a stack trace in the >> log. :) >> >> -Eric >> >> On Wed, Oct 18, 2017 at 2:31 PM, Celso Agra wrote: >> >>> I'll try to simulate that with another VM and API. >>> >>> I'll bring results soon as possible! >>> >>> 2017-10-18 15:21 GMT-03:00 Eric Wittmann : >>> >>>> Is there any chance that the Internal Server Error is coming from the >>>> API being proxied? :) >>>> >>>> -Eric >>>> >>>> >>>> On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra >>>> wrote: >>>> >>>>> Hi Eric, >>>>> >>>>> I look into "standalone/log/server.log", and I didn't see anything >>>>> about this. =/ >>>>> >>>>> Best Regards, >>>>> >>>>> Celso Agra >>>>> >>>>> >>>>> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >>>>> >>>>>> Are there any errors in the server logs that could help diagnose this >>>>>> issue? >>>>>> >>>>>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I got an "Internal Server Error" when I send a DELETE request method >>>>>>> and there is no Content-Type in header. I'd like to know if this is an >>>>>>> expected behavior, or something else should be configured? I'm using Apiman >>>>>>> 1.3.0.Final with CORS plugin. >>>>>>> >>>>>>> PS.: This behavior just occurs when I send a DELETE method request >>>>>>> through Apiman without "Content-Type" in header. >>>>>>> >>>>>>> Here is some examples: >>>>>>> >>>>>>> >>>>>>>> *Example 01 $ curl -X "DELETE" >>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>> **ErrorInternal >>>>>>>> Server Error* >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>> **[ >>>>>>>> { "return": "OK" } ]* >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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* >>> >> >> > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171018/e2d26717/attachment.html From celso.agra at gmail.com Wed Oct 18 23:12:11 2017 From: celso.agra at gmail.com (Celso Agra) Date: Thu, 19 Oct 2017 00:12:11 -0300 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: Hi Marc and Eric, I did a VM to simulate this issue. Here ir the project: https://github.com/celsoagra/apiman-json-server I created an apiman server with the API (json-server), and try to execute that with the same configs of my environment. But, I didn't get this Internal Server Error. So, problem could be on my environment. Thanks a lot for the attention Best Regards, Celso Agra 2017-10-18 18:24 GMT-03:00 Eric Wittmann : > OK thanks. I assumed that was the case but wanted to make sure! :) > > On Wed, Oct 18, 2017 at 4:33 PM, Celso Agra wrote: > >> The API works fine here! >> >> 2017-10-18 17:25 GMT-03:00 Eric Wittmann : >> >>> What I mean is: what happens if you bypass the apiman gateway and make >>> an identical curl request directly to the back-end API? >>> >>> I'm asking because I'm coming up empty on why an internal server error >>> could happen in the apiman gateway without generating a stack trace in the >>> log. :) >>> >>> -Eric >>> >>> On Wed, Oct 18, 2017 at 2:31 PM, Celso Agra >>> wrote: >>> >>>> I'll try to simulate that with another VM and API. >>>> >>>> I'll bring results soon as possible! >>>> >>>> 2017-10-18 15:21 GMT-03:00 Eric Wittmann : >>>> >>>>> Is there any chance that the Internal Server Error is coming from the >>>>> API being proxied? :) >>>>> >>>>> -Eric >>>>> >>>>> >>>>> On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra >>>>> wrote: >>>>> >>>>>> Hi Eric, >>>>>> >>>>>> I look into "standalone/log/server.log", and I didn't see anything >>>>>> about this. =/ >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Celso Agra >>>>>> >>>>>> >>>>>> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >>>>>> >>>>>>> Are there any errors in the server logs that could help diagnose >>>>>>> this issue? >>>>>>> >>>>>>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I got an "Internal Server Error" when I send a DELETE request >>>>>>>> method and there is no Content-Type in header. I'd like to know if this is >>>>>>>> an expected behavior, or something else should be configured? I'm using >>>>>>>> Apiman 1.3.0.Final with CORS plugin. >>>>>>>> >>>>>>>> PS.: This behavior just occurs when I send a DELETE method request >>>>>>>> through Apiman without "Content-Type" in header. >>>>>>>> >>>>>>>> Here is some examples: >>>>>>>> >>>>>>>> >>>>>>>>> *Example 01 $ curl -X "DELETE" >>>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>>> **ErrorInternal >>>>>>>>> Server Error* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Example 02 $ curl -H "Content-Type: application/json" -X "DELETE" >>>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>>> **[ >>>>>>>>> { "return": "OK" } ]* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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* >>>> >>> >>> >> >> >> -- >> --- >> *Celso Agra* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171019/02e627d8/attachment-0001.html From eric.wittmann at redhat.com Thu Oct 19 10:03:33 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 19 Oct 2017 10:03:33 -0400 Subject: [Apiman-user] Internal Server Error through DELETE method, when there is no Content-Type in header In-Reply-To: References: Message-ID: OK keep us posted on your progress. I'm still very surprised that there is no stack trace in the wildfly server logs. If you wanted to try attaching a Java debugger to it I'm sure we could point you in the right direction... On Wed, Oct 18, 2017 at 11:12 PM, Celso Agra wrote: > Hi Marc and Eric, > > I did a VM to simulate this issue. Here ir the project: > https://github.com/celsoagra/apiman-json-server > > I created an apiman server with the API (json-server), and try to execute > that with the same configs of my environment. But, I didn't get this > Internal Server Error. So, problem could be on my environment. > > Thanks a lot for the attention > > Best Regards, > > Celso Agra > > > 2017-10-18 18:24 GMT-03:00 Eric Wittmann : > >> OK thanks. I assumed that was the case but wanted to make sure! :) >> >> On Wed, Oct 18, 2017 at 4:33 PM, Celso Agra wrote: >> >>> The API works fine here! >>> >>> 2017-10-18 17:25 GMT-03:00 Eric Wittmann : >>> >>>> What I mean is: what happens if you bypass the apiman gateway and make >>>> an identical curl request directly to the back-end API? >>>> >>>> I'm asking because I'm coming up empty on why an internal server error >>>> could happen in the apiman gateway without generating a stack trace in the >>>> log. :) >>>> >>>> -Eric >>>> >>>> On Wed, Oct 18, 2017 at 2:31 PM, Celso Agra >>>> wrote: >>>> >>>>> I'll try to simulate that with another VM and API. >>>>> >>>>> I'll bring results soon as possible! >>>>> >>>>> 2017-10-18 15:21 GMT-03:00 Eric Wittmann : >>>>> >>>>>> Is there any chance that the Internal Server Error is coming from the >>>>>> API being proxied? :) >>>>>> >>>>>> -Eric >>>>>> >>>>>> >>>>>> On Wed, Oct 18, 2017 at 1:23 PM, Celso Agra >>>>>> wrote: >>>>>> >>>>>>> Hi Eric, >>>>>>> >>>>>>> I look into "standalone/log/server.log", and I didn't see anything >>>>>>> about this. =/ >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Celso Agra >>>>>>> >>>>>>> >>>>>>> 2017-10-18 9:22 GMT-03:00 Eric Wittmann : >>>>>>> >>>>>>>> Are there any errors in the server logs that could help diagnose >>>>>>>> this issue? >>>>>>>> >>>>>>>> On Tue, Oct 17, 2017 at 10:51 AM, Celso Agra >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I got an "Internal Server Error" when I send a DELETE request >>>>>>>>> method and there is no Content-Type in header. I'd like to know if this is >>>>>>>>> an expected behavior, or something else should be configured? I'm using >>>>>>>>> Apiman 1.3.0.Final with CORS plugin. >>>>>>>>> >>>>>>>>> PS.: This behavior just occurs when I send a DELETE method request >>>>>>>>> through Apiman without "Content-Type" in header. >>>>>>>>> >>>>>>>>> Here is some examples: >>>>>>>>> >>>>>>>>> >>>>>>>>>> *Example 01 $ curl -X "DELETE" >>>>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>>>> **ErrorInternal >>>>>>>>>> Server Error* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Example 02 $ curl -H "Content-Type: application/json" -X >>>>>>>>>> "DELETE" >>>>>>>>>> https://apiman.local/apiman-gateway/test-app/application/1.0/delete/99?apikey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>>>>>>>>> **[ >>>>>>>>>> { "return": "OK" } ]* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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* >>>>> >>>> >>>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171019/cda1e4b0/attachment.html From lchampagnac at vulog.com Thu Oct 19 12:04:33 2017 From: lchampagnac at vulog.com (Laurent Champagnac) Date: Thu, 19 Oct 2017 16:04:33 +0000 Subject: [Apiman-user] Apiman $CRYPT error after export/import In-Reply-To: References: , Message-ID: <1508429073519.21613@vulog.com> Hello guys, i just updated this issue. It should helps fixing that.... https://issues.jboss.org/browse/APIMAN-1201? Please revert if you can. Thanks, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171019/b9a9daac/attachment.html From marc.savy at redhat.com Mon Oct 23 01:27:27 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 23 Oct 2017 07:27:27 +0200 Subject: [Apiman-user] Apiman $CRYPT error after export/import In-Reply-To: <1508429073519.21613@vulog.com> References: <1508429073519.21613@vulog.com> Message-ID: Thanks for your patience (and thanks Eric for engaging in my stead!); I've been on holiday for the last few weeks so not able to respond as usual. This is definitely on my radar to fix soon (either forthcoming release or the one which will follow very shortly). On 19 October 2017 at 18:04, Laurent Champagnac wrote: > Hello guys, > > > i just updated this issue. It should helps fixing that.... > > > https://issues.jboss.org/browse/APIMAN-1201? > > > Please revert if you can. > > > Thanks, > > Laurent > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171023/96756a47/attachment.html