From harrytpc at gmail.com Wed Aug 10 17:45:53 2016 From: harrytpc at gmail.com (Harry Trinta) Date: Wed, 10 Aug 2016 18:45:53 -0300 Subject: [Apiman-user] Client App and CORS Message-ID: Dears, I've created a "client app" that has a lot of contracts with a lot of APIs. I'm having the following problem: In Cross-origen, when the browser send a OPTIONS request, it does not send the parameter X-API-Key. Then, the apiman returns a error: "API not public". Is possible to disable the X-API-Key validation of a "client app" when the request is OPTIONS type? Thanks, Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160810/d0afc451/attachment-0001.html From marc.savy at redhat.com Fri Aug 12 11:20:24 2016 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 12 Aug 2016 16:20:24 +0100 Subject: [Apiman-user] Client App and CORS In-Reply-To: References: Message-ID: Hi Harry, As an interim option you can transmit the key as a query parameter instead of a header (e.g. /a/b/c/?apiKey=FOO). But, I think you're right. As I understand the CORS spec, we should always allow an OPTIONS requests to (minimally) enter the policy chain, because browsers don't make a CORS preflight request with any custom headers (they simply don't transmit them). Under certain circumstances it might allow a client to hit a backend without a key when we don't want it to. Although I imagine the impact of this should generally be quite minimal. Others: Any thoughts? On 10 August 2016 at 22:45, Harry Trinta wrote: > Dears, > > I've created a "client app" that has a lot of contracts with a lot of APIs. > > I'm having the following problem: > > In Cross-origen, when the browser send a OPTIONS request, it does not send > the parameter X-API-Key. Then, the apiman returns a error: "API not public". > > > Is possible to disable the X-API-Key validation of a "client app" when the > request is OPTIONS type? > > Thanks, > Harry > > _______________________________________________ > 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/20160812/47de9005/attachment.html From eric.wittmann at redhat.com Fri Aug 12 12:08:50 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 12 Aug 2016 12:08:50 -0400 Subject: [Apiman-user] Client App and CORS In-Reply-To: References: Message-ID: <1383060d-95b0-89e2-ee4b-73421d9ca725@redhat.com> The problem with doing that is: how do we know what app is being used? And then, what happens if the CORS policy was configured either on the application or on the plan? Without the API key we won't know what app is making the call and we also won't know what plan to use. Perhaps a better solution is to handle CORS pre-flight requests separately? Before the request ever even reaches the apiman policy engine. It would be a relatively simple thing to implement a CorsPreflightOnlyFilter in the servlet implementation of the apiman gateway. However, isn't there specific pre-flight related information configured in the CORS policy itself? So perhaps a global filter wouldn't work well enough (since it wouldn't have information to those config settings). The best approach *may* be to pass the api key in the URL. -Eric On 8/12/2016 11:20 AM, Marc Savy wrote: > Hi Harry, > > As an interim option you can transmit the key as a query parameter > instead of a header (e.g. /a/b/c/?apiKey=FOO). > > But, I think you're right. As I understand the CORS spec, we should > always allow an OPTIONS requests to (minimally) enter the policy chain, > because browsers don't make a CORS preflight request with any custom > headers (they simply don't transmit them). > > Under certain circumstances it might allow a client to hit a backend > without a key when we don't want it to. Although I imagine the impact of > this should generally be quite minimal. > > Others: Any thoughts? > > On 10 August 2016 at 22:45, Harry Trinta > wrote: > > Dears, > > I've created a "client app" that has a lot of contracts with a lot > of APIs. > > I'm having the following problem: > > In Cross-origen, when the browser send a OPTIONS request, it > does not send the parameter X-API-Key. Then, the apiman returns > a error: "API not public". > > > Is possible to disable the X-API-Key validation of a "client app" > when the request is OPTIONS type? > > Thanks, > Harry > > _______________________________________________ > 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 > From eric.wittmann at redhat.com Fri Aug 19 11:19:54 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 19 Aug 2016 11:19:54 -0400 Subject: [Apiman-user] Update: apiman and 3scale Message-ID: Hey everyone. We mentioned it a couple of months ago when the news was fresh, but just as a reminder, Red Hat has acquired 3scale technologies. This has resulted in a change in priority with respect to API Management work within the company. As you can imagine, the apiman team in particular has been impacted. To help everyone understand the future of apiman, we've put together a blog post to answer some common questions. You can find it here: http://www.apiman.io/blog/apiman/3scale/2016/08/19/3scale-apiman-part2.html Anyone with additional questions or comments, please feel free to do so here, or in any of the other various places we try to communicate (comments on the blog post, IRC, twitter, etc). Always happy to have conversations with our fantastic community! :) -Eric From ryordan at redhat.com Fri Aug 19 12:29:13 2016 From: ryordan at redhat.com (Rachel Yordan) Date: Fri, 19 Aug 2016 12:29:13 -0400 Subject: [Apiman-user] Update: apiman and 3scale In-Reply-To: References: Message-ID: Just wanted to add that we have started a Reddit thread for those of you interested in joining the conversation: https://www.reddit.com/r/programming/comments/4yjn9c/future_of_apiman_project_after_red_hats/ Or on Twitter: https://twitter.com/apiman_io/status/766655829332242432 Rachel On Fri, Aug 19, 2016 at 11:19 AM, Eric Wittmann wrote: > Hey everyone. We mentioned it a couple of months ago when the news was > fresh, but just as a reminder, Red Hat has acquired 3scale technologies. > This has resulted in a change in priority with respect to API > Management work within the company. As you can imagine, the apiman team > in particular has been impacted. > > To help everyone understand the future of apiman, we've put together a > blog post to answer some common questions. You can find it here: > > http://www.apiman.io/blog/apiman/3scale/2016/08/19/ > 3scale-apiman-part2.html > > Anyone with additional questions or comments, please feel free to do so > here, or in any of the other various places we try to communicate > (comments on the blog post, IRC, twitter, etc). Always happy to have > conversations with our fantastic community! :) > > -Eric > _______________________________________________ > 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/20160819/f4554ed2/attachment.html From Melih.Ozdemirkan at avivasa.com.tr Thu Aug 25 03:53:41 2016 From: Melih.Ozdemirkan at avivasa.com.tr (Melih Ozdemirkan) Date: Thu, 25 Aug 2016 07:53:41 +0000 Subject: [Apiman-user] CORS preflight OPTIONS request requires Authorization header Message-ID: <7c7de17679d447d6bd98fdeb8151d06f@AVSBIMEXCH01.avivasa.local> I have an API provisioned on APIMAN with Keycloak OAuth Policy and CORS Policy (using APIMAN Plugins) . Onclient side, I get the JWT token from Keycloak and add authorization header to get request sent to APIMAN for my own API. Problem is that APIMAN rejects OPTIONS preflight with 401 Unauthorized with message "OAuth2 'Authorization' header or 'access_token' query parameter must be provided." I am using APIMAN 1.2.7_final . I applied workaround in the JIRA issue given below but it didn't work for me. Does it work for both APIMAN's own rest endpoints and my own API's. I suppose it is not valid for the later one. http://lists.jboss.org/pipermail/apiman-user/2016-July/000727.html https://issues.jboss.org/browse/APIMAN-1209 TOKEN REQUEST TO KEYCLOAK General Request URL:http://localhost:8280/auth/realms/company/protocol/openid-connect/token Request Method:POST Status Code:200 OK Remote Address:127.0.0.1:8280 Response Headers Access-Control-Allow-Credentials:true Access-Control-Allow-Origin:http://localhost:8080 Access-Control-Expose-Headers:Access-Control-Allow-Methods Connection:keep-alive Content-Length:3175 Content-Type:application/json Date:Thu, 25 Aug 2016 07:22:59 GMT Server:WildFly/10 X-Powered-By:Undertow/1 Request Headers Accept:*/* Accept-Encoding:gzip, deflate Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 Connection:keep-alive Content-Length:78 Content-Type:application/x-www-form-urlencoded Host:localhost:8280 Origin:http://localhost:8080 Referer:http://localhost:8080/login-services/login.html User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Form Data view source view URL encoded username:username password:pasword grant_type:password client_id:company GET REQUEST TO API on APIMAN General Request URL:http://localhost:8280/apiman-gateway/client/test-services-ws/1.0/getuser/ Request Method:OPTIONS Status Code:401 Unauthorized Remote Address:127.0.0.1:8280 Response Headers Connection:keep-alive Content-Type:application/json Date:Thu, 25 Aug 2016 07:22:59 GMT Server:WildFly/10 Transfer-Encoding:chunked X-Policy-Failure-Code:11005 X-Policy-Failure-Message:OAuth2 'Authorization' header or 'access_token' query parameter must be provided. X-Policy-Failure-Type:Authentication X-Powered-By:Undertow/1 Request Headers Accept:*/* Accept-Encoding:gzip, deflate, sdch Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 Access-Control-Request-Headers:authorization Access-Control-Request-Method:GET Connection:keep-alive Host:localhost:8280 Origin:http://localhost:8080 Referer:http://localhost:8080/login-services/login.html User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 ?yi ?al??malar, Melih ?zdemirkan AvivaSA Emeklilik ve Hayat A.?. Kanal ve Entegrasyon Uygulamalar? Dan??man www.avivasa.com.tr Saray Mah. Dr. Adnan B?y?kdeniz Cad. No:12 34768 ?mraniye - ?stanbul [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_01.png] [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_02.png] [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_03.png] Bu e-postanin i?erdigi bilgiler (ekleri dahil olmak ?zere) gizlidir. Onayimiz olmaksizin ???nc? kisilere a?iklanamaz. Bu mesajin g?nderilmek istendigi kisi degilseniz, l?tfen mesaji sisteminizden derhal siliniz. AvivaSA Emeklilik ve Hayat A.S. bu mesajin i?erdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda bir garanti vermemektedir. Bu nedenle bilgilerin ne sekilde olursa olsun i?eriginden, iletilmesinden, alinmasindan, saklanmasindan sorumlu degildir. Bu mesajin bilinen vir?slere karsi kontrolleri AvivaSA Emeklilik ve Hayat A.S. tarafindan yapilmistir. Ancak internet iletisiminde g?venlik ve hatasiz g?nderim garanti edilemeyeceginden, mesajin yerine ulasmamasi, ge? ulasmasi, i?eriginin bozulmasi ya da mesajin vir?s tasimasi gibi problemler olusabilir. AvivaSA Emeklilik ve Hayat A.S. bu tip sorunlardan sorumlu tutulmaz. Bu mesajin i?erigi yazarina ait olup AvivaSA Emeklilik ve Hayat A.S.'nin g?r?slerini i?ermeyebilir. The information contained in this e-mail (including any attachments) is confidential. It must not be disclosed to any person without our authority. If you are not the intended recipient, please delete it from your system immediately. AvivaSA Emeklilik ve Hayat A.S. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. This message is scanned for known viruses by AvivaSA Emeklilik ve Hayat A.S. But Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The AvivaSA Emeklilik ve Hayat A.S. therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of AvivaSA Emeklilik ve Hayat A.S. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160825/4f2136bd/attachment-0001.html From eric.wittmann at redhat.com Mon Aug 29 08:48:54 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 29 Aug 2016 08:48:54 -0400 Subject: [Apiman-user] CORS preflight OPTIONS request requires Authorization header In-Reply-To: <7c7de17679d447d6bd98fdeb8151d06f@AVSBIMEXCH01.avivasa.local> References: <7c7de17679d447d6bd98fdeb8151d06f@AVSBIMEXCH01.avivasa.local> Message-ID: Yeah the JIRA you referenced is specifically a problem with CORS on the gateway's own API (not APIs proxied by the gateway). Do you have the CORS policy configured *before* the Keycloak OAuth policy? I'd have to check the implementation, but I would think that pre-flight (options) requests would return an immediate reponse (by the CORS plugin) and thus never reach the OAuth policy. If that's not happening, then perhaps that is a bug in the CORS policy... @msvay - any thoughts on this? -Eric On 8/25/2016 3:53 AM, Melih Ozdemirkan wrote: > I have an API provisioned on APIMAN with Keycloak OAuth Policy and CORS > Policy (using APIMAN Plugins) . Onclient side, I get the JWT token from > Keycloak and add authorization header to get request sent to APIMAN for > my own API. Problem is that APIMAN rejects OPTIONS preflight with 401 > Unauthorized with message "OAuth2 'Authorization' header or > 'access_token' query parameter must be provided." > > > > I am using APIMAN 1.2.7_final . I applied workaround in the JIRA issue > given below but it didn?t work for me. Does it work for both APIMAN?s > own rest endpoints and my own API?s. I suppose it is not valid for the > later one. > > > > http://lists.jboss.org/pipermail/apiman-user/2016-July/000727.html > > > https://issues.jboss.org/browse/APIMAN-1209 > > > > > > *TOKEN REQUEST TO KEYCLOAK* > > *General* > > Request > URL:http://localhost:8280/auth/realms/company/protocol/openid-connect/token > > Request Method:POST > > Status Code:200 OK > > Remote Address:127.0.0.1:8280 > > > > *Response Headers* > > Access-Control-Allow-Credentials:true > > Access-Control-Allow-Origin:http://localhost:8080 > > Access-Control-Expose-Headers:Access-Control-Allow-Methods > > Connection:keep-alive > > Content-Length:3175 > > Content-Type:application/json > > Date:Thu, 25 Aug 2016 07:22:59 GMT > > Server:WildFly/10 > > X-Powered-By:Undertow/1 > > > > *Request Headers* > > Accept:*/* > > Accept-Encoding:gzip, deflate > > Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 > > Connection:keep-alive > > Content-Length:78 > > Content-Type:application/x-www-form-urlencoded > > Host:localhost:8280 > > Origin:http://localhost:8080 > > Referer:http://localhost:8080/login-services/login.html > > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 > > Form Data > > view source > > view URL encoded > > username:username > > password:pasword > > grant_type:password > > client_id:company > > > > > > *GET REQUEST TO API on APIMAN *** > > *General* > > Request > URL:http://localhost:8280/apiman-gateway/client/test-services-ws/1.0/getuser/ > > Request Method:OPTIONS > > Status Code:*401 Unauthorized* > > Remote Address:127.0.0.1:8280 > > > > *Response Headers* > > Connection:keep-alive > > Content-Type:application/json > > Date:Thu, 25 Aug 2016 07:22:59 GMT > > Server:WildFly/10 > > Transfer-Encoding:chunked > > X-Policy-Failure-Code:11005 > > X-Policy-Failure-Message:*OAuth2 'Authorization' header or > 'access_token' query parameter must be provided*. > > X-Policy-Failure-Type:Authentication > > X-Powered-By:Undertow/1 > > > > *Request Headers* > > Accept:*/* > > Accept-Encoding:gzip, deflate, sdch > > Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 > > Access-Control-Request-Headers:authorization > > Access-Control-Request-Method:GET > > Connection:keep-alive > > Host:localhost:8280 > > Origin:http://localhost:8080 > > Referer:http://localhost:8080/login-services/login.html > > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 > > > > > > ?yi ?al??malar, > > * * > > *Melih ?zdemirkan* > > *AvivaSA Emeklilik ve Hayat A.?.* > > *Kanal ve Entegrasyon Uygulamalar? * > > *Dan??man* > > *www.avivasa.com.tr * > > *Saray Mah. Dr. Adnan B?y?kdeniz Cad. No:12 34768* > > *?mraniye ? ?stanbul* > > > > > > > > Bu e-postanin i?erdigi bilgiler (ekleri dahil olmak ?zere) gizlidir. > Onayimiz olmaksizin ???nc? kisilere a?iklanamaz. Bu mesajin g?nderilmek > istendigi kisi degilseniz, l?tfen mesaji sisteminizden derhal siliniz. > AvivaSA Emeklilik ve Hayat A.S. bu mesajin i?erdigi bilgilerin dogrulugu > veya eksiksiz oldugu konusunda bir garanti vermemektedir. Bu nedenle > bilgilerin ne sekilde olursa olsun i?eriginden, iletilmesinden, > alinmasindan, saklanmasindan sorumlu degildir. Bu mesajin bilinen > vir?slere karsi kontrolleri AvivaSA Emeklilik ve Hayat A.S. tarafindan > yapilmistir. Ancak internet iletisiminde g?venlik ve hatasiz g?nderim > garanti edilemeyeceginden, mesajin yerine ulasmamasi, ge? ulasmasi, > i?eriginin bozulmasi ya da mesajin vir?s tasimasi gibi problemler > olusabilir. AvivaSA Emeklilik ve Hayat A.S. bu tip sorunlardan sorumlu > tutulmaz. Bu mesajin i?erigi yazarina ait olup AvivaSA Emeklilik ve > Hayat A.S.'nin g?r?slerini i?ermeyebilir. > > The information contained in this e-mail (including any attachments) is > confidential. It must not be disclosed to any person without our > authority. If you are not the intended recipient, please delete it from > your system immediately. AvivaSA Emeklilik ve Hayat A.S. makes no > warranty as to the accuracy or completeness of any information contained > in this message and hereby excludes any liability of any kind for the > information contained therein or for the information transmission, > reception, storage or use of such in any way whatsoever. This message is > scanned for known viruses by AvivaSA Emeklilik ve Hayat A.S. But > Internet communications cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, arrive late or > contain viruses. The AvivaSA Emeklilik ve Hayat A.S. therefore does not > accept liability for any errors or omissions in the context of this > message which arise as a result of Internet transmission. Any opinions > expressed in this message are those of the author and may not > necessarily reflect the opinions of AvivaSA Emeklilik ve Hayat A.S. > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From Melih.Ozdemirkan at avivasa.com.tr Wed Aug 31 10:30:32 2016 From: Melih.Ozdemirkan at avivasa.com.tr (Melih Ozdemirkan) Date: Wed, 31 Aug 2016 14:30:32 +0000 Subject: [Apiman-user] CORS preflight OPTIONS request requires Authorization header In-Reply-To: References: <7c7de17679d447d6bd98fdeb8151d06f@AVSBIMEXCH01.avivasa.local> Message-ID: <47bd5310d2374542882c85709295d5fc@AVSBIMEXCH01.avivasa.local> Having CORS policy configured just before than Keycloak OAuth policy did the trick. Many thanks for your help . By the way, it would be good to have this behaviour documented or to have a warning on plugin configuration page. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: Monday, August 29, 2016 3:49 PM To: Melih Ozdemirkan ; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] CORS preflight OPTIONS request requires Authorization header Yeah the JIRA you referenced is specifically a problem with CORS on the gateway's own API (not APIs proxied by the gateway). Do you have the CORS policy configured *before* the Keycloak OAuth policy? I'd have to check the implementation, but I would think that pre-flight (options) requests would return an immediate reponse (by the CORS plugin) and thus never reach the OAuth policy. If that's not happening, then perhaps that is a bug in the CORS policy... @msvay - any thoughts on this? -Eric On 8/25/2016 3:53 AM, Melih Ozdemirkan wrote: > I have an API provisioned on APIMAN with Keycloak OAuth Policy and > CORS Policy (using APIMAN Plugins) . Onclient side, I get the JWT > token from Keycloak and add authorization header to get request sent > to APIMAN for my own API. Problem is that APIMAN rejects OPTIONS > preflight with 401 Unauthorized with message "OAuth2 'Authorization' > header or 'access_token' query parameter must be provided." > > > > I am using APIMAN 1.2.7_final . I applied workaround in the JIRA issue > given below but it didn?t work for me. Does it work for both APIMAN?s > own rest endpoints and my own API?s. I suppose it is not valid for the > later one. > > > > http://lists.jboss.org/pipermail/apiman-user/2016-July/000727.html > > > https://issues.jboss.org/browse/APIMAN-1209 > > > > > > *TOKEN REQUEST TO KEYCLOAK* > > *General* > > Request > URL:http://localhost:8280/auth/realms/company/protocol/openid-connect/ > token > > Request Method:POST > > Status Code:200 OK > > Remote Address:127.0.0.1:8280 > > > > *Response Headers* > > Access-Control-Allow-Credentials:true > > Access-Control-Allow-Origin:http://localhost:8080 > > Access-Control-Expose-Headers:Access-Control-Allow-Methods > > Connection:keep-alive > > Content-Length:3175 > > Content-Type:application/json > > Date:Thu, 25 Aug 2016 07:22:59 GMT > > Server:WildFly/10 > > X-Powered-By:Undertow/1 > > > > *Request Headers* > > Accept:*/* > > Accept-Encoding:gzip, deflate > > Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 > > Connection:keep-alive > > Content-Length:78 > > Content-Type:application/x-www-form-urlencoded > > Host:localhost:8280 > > Origin:http://localhost:8080 > > Referer:http://localhost:8080/login-services/login.html > > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 > > Form Data > > view source > > view URL encoded > > username:username > > password:pasword > > grant_type:password > > client_id:company > > > > > > *GET REQUEST TO API on APIMAN *** > > *General* > > Request > URL:http://localhost:8280/apiman-gateway/client/test-services-ws/1.0/g > etuser/ > > Request Method:OPTIONS > > Status Code:*401 Unauthorized* > > Remote Address:127.0.0.1:8280 > > > > *Response Headers* > > Connection:keep-alive > > Content-Type:application/json > > Date:Thu, 25 Aug 2016 07:22:59 GMT > > Server:WildFly/10 > > Transfer-Encoding:chunked > > X-Policy-Failure-Code:11005 > > X-Policy-Failure-Message:*OAuth2 'Authorization' header or > 'access_token' query parameter must be provided*. > > X-Policy-Failure-Type:Authentication > > X-Powered-By:Undertow/1 > > > > *Request Headers* > > Accept:*/* > > Accept-Encoding:gzip, deflate, sdch > > Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 > > Access-Control-Request-Headers:authorization > > Access-Control-Request-Method:GET > > Connection:keep-alive > > Host:localhost:8280 > > Origin:http://localhost:8080 > > Referer:http://localhost:8080/login-services/login.html > > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 > > > > > > ?yi ?al??malar, > > * * > > *Melih ?zdemirkan* > > *AvivaSA Emeklilik ve Hayat A.?.* > > *Kanal ve Entegrasyon Uygulamalar? * > > *Dan??man* > > *www.avivasa.com.tr * > > *Saray Mah. Dr. Adnan B?y?kdeniz Cad. No:12 34768* > > *?mraniye ? ?stanbul* > > > > > > > > Bu e-postanin i?erdigi bilgiler (ekleri dahil olmak ?zere) gizlidir. > Onayimiz olmaksizin ???nc? kisilere a?iklanamaz. Bu mesajin > g?nderilmek istendigi kisi degilseniz, l?tfen mesaji sisteminizden derhal siliniz. > AvivaSA Emeklilik ve Hayat A.S. bu mesajin i?erdigi bilgilerin > dogrulugu veya eksiksiz oldugu konusunda bir garanti vermemektedir. Bu > nedenle bilgilerin ne sekilde olursa olsun i?eriginden, > iletilmesinden, alinmasindan, saklanmasindan sorumlu degildir. Bu > mesajin bilinen vir?slere karsi kontrolleri AvivaSA Emeklilik ve Hayat > A.S. tarafindan yapilmistir. Ancak internet iletisiminde g?venlik ve > hatasiz g?nderim garanti edilemeyeceginden, mesajin yerine ulasmamasi, > ge? ulasmasi, i?eriginin bozulmasi ya da mesajin vir?s tasimasi gibi > problemler olusabilir. AvivaSA Emeklilik ve Hayat A.S. bu tip > sorunlardan sorumlu tutulmaz. Bu mesajin i?erigi yazarina ait olup > AvivaSA Emeklilik ve Hayat A.S.'nin g?r?slerini i?ermeyebilir. > > The information contained in this e-mail (including any attachments) > is confidential. It must not be disclosed to any person without our > authority. If you are not the intended recipient, please delete it > from your system immediately. AvivaSA Emeklilik ve Hayat A.S. makes no > warranty as to the accuracy or completeness of any information > contained in this message and hereby excludes any liability of any > kind for the information contained therein or for the information > transmission, reception, storage or use of such in any way whatsoever. > This message is scanned for known viruses by AvivaSA Emeklilik ve > Hayat A.S. But Internet communications cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, > lost, arrive late or contain viruses. The AvivaSA Emeklilik ve Hayat > A.S. therefore does not accept liability for any errors or omissions > in the context of this message which arise as a result of Internet > transmission. Any opinions expressed in this message are those of the > author and may not necessarily reflect the opinions of AvivaSA Emeklilik ve Hayat A.S. > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_01.png] [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_02.png] [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_03.png] Bu e-postanin i?erdigi bilgiler (ekleri dahil olmak ?zere) gizlidir. Onayimiz olmaksizin ???nc? kisilere a?iklanamaz. Bu mesajin g?nderilmek istendigi kisi degilseniz, l?tfen mesaji sisteminizden derhal siliniz. AvivaSA Emeklilik ve Hayat A.S. bu mesajin i?erdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda bir garanti vermemektedir. Bu nedenle bilgilerin ne sekilde olursa olsun i?eriginden, iletilmesinden, alinmasindan, saklanmasindan sorumlu degildir. Bu mesajin bilinen vir?slere karsi kontrolleri AvivaSA Emeklilik ve Hayat A.S. tarafindan yapilmistir. Ancak internet iletisiminde g?venlik ve hatasiz g?nderim garanti edilemeyeceginden, mesajin yerine ulasmamasi, ge? ulasmasi, i?eriginin bozulmasi ya da mesajin vir?s tasimasi gibi problemler olusabilir. AvivaSA Emeklilik ve Hayat A.S. bu tip sorunlardan sorumlu tutulmaz. Bu mesajin i?erigi yazarina ait olup AvivaSA Emeklilik ve Hayat A.S.'nin g?r?slerini i?ermeyebilir. The information contained in this e-mail (including any attachments) is confidential. It must not be disclosed to any person without our authority. If you are not the intended recipient, please delete it from your system immediately. AvivaSA Emeklilik ve Hayat A.S. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. This message is scanned for known viruses by AvivaSA Emeklilik ve Hayat A.S. But Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The AvivaSA Emeklilik ve Hayat A.S. therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of AvivaSA Emeklilik ve Hayat A.S. From eric.wittmann at redhat.com Wed Aug 31 20:12:14 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 31 Aug 2016 20:12:14 -0400 Subject: [Apiman-user] Apiman & Elasticsearch In-Reply-To: References: Message-ID: <7a8338dd-7ff5-42ce-09b0-2e1031cf0ac1@redhat.com> Hi St?phane. Yes, it is possible to run apiman without using Elasticsearch at all. You mentioned that you already replaced ES with mysql for the gateway registry. There are several other components as well, including metrics. We have documentation for metrics here: http://www.apiman.io/latest/installation-guide.html#_how_to_use_a_sql_database_to_store_and_retrieve_metrics_replacing_elasticsearch In addition, here is an example apiman.properties config that uses alternatives for everything (Gateway only): https://gist.github.com/EricWittmann/822911517aa357b8c8c94c3ec79a32f3 Note that several of the components use Infinispan instead of elasticsearch. In order to use the Infinispan components you'll need to be using Wildfly *and* also add the following in your standalone-apiman.xml file (in the right spot in that file): https://gist.github.com/EricWittmann/437432397f03270737d9fbd9bdadeaea There are other choices for these components, but currently only the Elasticsearch and Infinispan implementations support multiple gateway nodes. If you're just running a single Gateway node, you could use the in-memory implementations of these components (although you would lose state if the server was restarted). As for production references, I'm sorry to say that we don't really solicit that information in the community. However I have CC'd this response on the apiman users mailing list so perhaps someone will raise a hand and describe their production experience. :) -Eric On 8/31/2016 1:30 PM, St?phane Riegel wrote: > Hi Eric, > > > > I was interested on apiman opensource project and had a look on the > configuration part and have two questions: > > > Is it a way to not use elasticsearch at all on the project (gateway, > metrics, rate ?) ? Are there alternatives backend like MySQL for all > these elasticsearch features. I succeed to replace the gateway > information with MySQL but not all others features (metrics, rate ?). > > > Do you know if this project has some references in production? > > > Thanks a lot. > > > > Best regards, > > > > St?phane >