From chttl582 at gmail.com Thu Dec 6 03:02:20 2018 From: chttl582 at gmail.com (Jon Huang) Date: Thu, 6 Dec 2018 16:02:20 +0800 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Dear Eric Thanks for your explanation. I tried to deploy another gateway with a new storage(Elasticsearch) and configure API to publish on the new one. (API manager version 1.5.1) However when I tried to create a contract between API and client apps then re-register client apps, error happened. It seems API manager fails to connect to gateway2. (But UI-> Manage Gateways -> Edit Gateway -> Test Gateway returns *Gateway Configuration Valid*) (io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to register client.) I put detail log in attachment if you are interested. Thanks simple diagram for my deployment test. [image: image.png] Volk, Florian ? 2018?11?30? ?? ??10:24??? > Hi Eric, > > > > thanks for this detailed answer J > > This is quite interesting. We didn?t expected this behavior. Maybe it > would be good to place this in the documentation, maybe with this picture ;) > > > > But this raises a few new questions for us. I try to explain: > > > > ? Do we need for *alternate* setup two UIs if we don?t want to > use the REST interface or CLI-Tool? > > o One for ?Gateway Alpha? and one for ?Gateway Beta?? > > o Because I think you can only connect one elasticseach instance with > the UI. Am I right on this? > > o What about the metrics in this use case ? leads to two UIs? > > > > ? For the ?one logical gateway? > > o If I understand you correctly this would mean that I also have to > configure only one gateway in my UI and can add X more without adding them > into the UI. > I just have to point them against the same elasticsearch instance. > > I also post this mail to the github issue, so we can stay within the > mailinglist. > > > > Thanks again, > > Florian > > > > > > *Von:* Eric Wittmann > *Gesendet:* Friday, 30 November 2018 14:57 > *An:* Volk, Florian > *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, > Benjamin ; Gebert, Alfred < > Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org > *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway > > > > Sure no problem. The typical use-case for having multiple Gateway nodes > is to scale the gateway layer horizontally and then put a load balancer in > front of them. So for example you might start up 5 apiman gateway > instances and configure them all to use the same Elasticsearch instance for > persistence (i.e. where to store configuration info like which APIs have > been published). In this use-case, every gateway instance has the same set > of APIs "published" to it. You can publish an API from the UI/manager to > **any** of the gateway instances and they will all know about that API. > This is the "Single Logical Gateway" use-case -- the UI/manager and all > consumers don't know or care how many gateway nodes there are - there could > be 1 node, or there could be 100. It behaves the same logically. > > > > An **alternate** use case for having multiple gateways is when you > actually want different APIs to be deployed to different gateways. So > let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, > B, and C. Then you have Gateway Beta which you want to proxy traffic to > APIs C, D, and E. In that case, consumer traffic MUST be routed through > Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be > routed through Gateway Beta to access APIs D and E. Finally, consumer > traffic can be routed to **either** Gateway Alpha or Gateway Beta in order > to access API C. Think of this as the "Two Logical Gateways" use-case. > > > > In order to achieve the "Two Logical Gateways" use-case, you will need > **two** separate persistence stores (Elasticsearch instances). Then you > configure Gateway Alpha to use persistence store #1 and configure Gateway > Beta to use persistence store #2. > > > > Note that you can have multiple gateway nodes for EACH of the two logical > gateways. So for example you could have 5 gateway instances all pointing > to persistence store #1 - these 5 nodes would make up a single logical > gateway called "Gateway Alpha". Then you could have 10 gateway instances > all pointing to persistence store #2 - and these would be a single logical > gateway called "Gateway Beta". > > > > Here is a diagram of what the architecture might look like: > > > > [image: image.png] > > > > > > On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < > Florian.Volk at scheer-group.com> wrote: > > Hi Eric, > > > > now I?m confused. We use Elasticsearch as backend. If I understand you > correctly it would mean that we have to setup an Elasticsearch instance for > each gateway? > > On the other point, if the gateways operate as logical unit, why is there > a configuration option in the ui? > > > > Can you explain this a little bit more detailed? Maybe you have a > configuration example. > > > > Regards, > Florian > > > > *Von:* Eric Wittmann > *Gesendet:* Friday, 30 November 2018 14:22 > *An:* Volk, Florian > *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, > Benjamin ; Gebert, Alfred < > Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org > *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway > > > > Are both gateways using the same persistent storage? Each gateway would > need separate, independent persistence otherwise they will behave as a > single "logical" gateway. > > > > -Eric > > > > > > On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < > Florian.Volk at scheer-group.com> wrote: > > Hello together, > > > > I was interested in this and made a short test in my loacal environment > and I am able to reproduce this. > > I created a ticket on github for this ( > https://github.com/apiman/apiman/issues/711). We may can fix this shortly. > > > > Regards, > > Florian > > > > *Von:* apiman-user-bounces at lists.jboss.org < > apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang > *Gesendet:* Friday, 30 November 2018 03:28 > *An:* marc.savy at redhat.com > *Cc:* apiman-user at lists.jboss.org > *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway > > > > Dear Marc > > > > Yes I untick another gateway however request towards both gateways still > works. > > Besides I tried to publish API via admin REST API (post api version then > put gateway info), both gateways forwards request too. > > Before filing a bug is there any apigw setting I shall check? (such as > parameter in apiman.properties or etc...) > > Thanks for your help. > > Regards > > Marc Savy ? 2018?11?21? ?? ??9:35??? > > Apologies for the terribly slow reply. We've had so much spam I've missed > legitimate emails like this. > > > > Did you explicitly untick the other gateway? Was this via the UI or the > API? > > > > Did you resolve this issue? If not, please file a bug: > https://github.com/apiman/apiman/issues > > > > On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: > > Dears > > > > I had set up 2 gateways. > > When I new an API, I have to choose which gateway to publish. (select list > at Gateway section in the implementation tab). > > However after creating a client app and contract for test, I found request > via another gateway still works. > > (I guest when publishing to gateway 1 and request via gateway 2 shall fail) > > Am I misunderstanding or I miss some settings to make it work? > > Thanks > > _______________________________________________ > 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/20181206/3b83f275/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 82777 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181206/3b83f275/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18859 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181206/3b83f275/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 82777 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181206/3b83f275/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: client_re_register_fail.log Type: application/octet-stream Size: 8903 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181206/3b83f275/attachment-0001.obj From eric.wittmann at redhat.com Thu Dec 6 08:47:21 2018 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 6 Dec 2018 08:47:21 -0500 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Your diagram looks exactly right. I don't know why you are getting a 404 error when trying to register the client. My best guess is that your Gateway 2 configuration is actually incorrect and that the "Test Gateway" function is returning a false positive somehow. Can you post the configuration settings you are using for *BOTH* of your Gateways? (I assume you can successfully publish an API to Gateway 1). You should be able to manually confirm your Gateway settings using e.g. curl or postman. There is an endpoint on the Gateway API that you can hit: GATEWAY_API_URL/system/status You'll need to provide auth info for this to work, but it will return a JSON response like this: { "id": "xyz", "name": "Apiman Gateway API", "description": "... something here ...", "version": "x.y.z", "up": true } The UI should be checking that endpoint when you click the "Test Gateway" button, but perhaps there's a bug in that. If the above endpoint can be hit and verified, then I'm at a complete loss as to why you'd be getting a 404 when trying to publish! The implication is that the Gateway API endpoint that the UI is attempting to use is missing. But if /system/status can be found, then everything else should be available too! @Marc Savy - any thoughts on this? -Eric On Thu, Dec 6, 2018 at 3:02 AM Jon Huang wrote: > Dear Eric > > Thanks for your explanation. > I tried to deploy another gateway with a new storage(Elasticsearch) and > configure API to publish on the new one. (API manager version 1.5.1) > However when I tried to create a contract between API and client apps then > re-register client apps, error happened. > It seems API manager fails to connect to gateway2. (But UI-> Manage > Gateways -> Edit Gateway -> Test Gateway returns *Gateway Configuration > Valid*) > (io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed > to register client.) > I put detail log in attachment if you are interested. > Thanks > > simple diagram for my deployment test. > [image: image.png] > > > Volk, Florian ? 2018?11?30? ?? ??10:24??? > >> Hi Eric, >> >> >> >> thanks for this detailed answer J >> >> This is quite interesting. We didn?t expected this behavior. Maybe it >> would be good to place this in the documentation, maybe with this picture ;) >> >> >> >> But this raises a few new questions for us. I try to explain: >> >> >> >> ? Do we need for *alternate* setup two UIs if we don?t want to >> use the REST interface or CLI-Tool? >> >> o One for ?Gateway Alpha? and one for ?Gateway Beta?? >> >> o Because I think you can only connect one elasticseach instance with >> the UI. Am I right on this? >> >> o What about the metrics in this use case ? leads to two UIs? >> >> >> >> ? For the ?one logical gateway? >> >> o If I understand you correctly this would mean that I also have to >> configure only one gateway in my UI and can add X more without adding them >> into the UI. >> I just have to point them against the same elasticsearch instance. >> >> I also post this mail to the github issue, so we can stay within the >> mailinglist. >> >> >> >> Thanks again, >> >> Florian >> >> >> >> >> >> *Von:* Eric Wittmann >> *Gesendet:* Friday, 30 November 2018 14:57 >> *An:* Volk, Florian >> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >> Benjamin ; Gebert, Alfred < >> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >> >> >> >> Sure no problem. The typical use-case for having multiple Gateway nodes >> is to scale the gateway layer horizontally and then put a load balancer in >> front of them. So for example you might start up 5 apiman gateway >> instances and configure them all to use the same Elasticsearch instance for >> persistence (i.e. where to store configuration info like which APIs have >> been published). In this use-case, every gateway instance has the same set >> of APIs "published" to it. You can publish an API from the UI/manager to >> **any** of the gateway instances and they will all know about that API. >> This is the "Single Logical Gateway" use-case -- the UI/manager and all >> consumers don't know or care how many gateway nodes there are - there could >> be 1 node, or there could be 100. It behaves the same logically. >> >> >> >> An **alternate** use case for having multiple gateways is when you >> actually want different APIs to be deployed to different gateways. So >> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, >> B, and C. Then you have Gateway Beta which you want to proxy traffic to >> APIs C, D, and E. In that case, consumer traffic MUST be routed through >> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be >> routed through Gateway Beta to access APIs D and E. Finally, consumer >> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order >> to access API C. Think of this as the "Two Logical Gateways" use-case. >> >> >> >> In order to achieve the "Two Logical Gateways" use-case, you will need >> **two** separate persistence stores (Elasticsearch instances). Then you >> configure Gateway Alpha to use persistence store #1 and configure Gateway >> Beta to use persistence store #2. >> >> >> >> Note that you can have multiple gateway nodes for EACH of the two logical >> gateways. So for example you could have 5 gateway instances all pointing >> to persistence store #1 - these 5 nodes would make up a single logical >> gateway called "Gateway Alpha". Then you could have 10 gateway instances >> all pointing to persistence store #2 - and these would be a single logical >> gateway called "Gateway Beta". >> >> >> >> Here is a diagram of what the architecture might look like: >> >> >> >> [image: image.png] >> >> >> >> >> >> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < >> Florian.Volk at scheer-group.com> wrote: >> >> Hi Eric, >> >> >> >> now I?m confused. We use Elasticsearch as backend. If I understand you >> correctly it would mean that we have to setup an Elasticsearch instance for >> each gateway? >> >> On the other point, if the gateways operate as logical unit, why is there >> a configuration option in the ui? >> >> >> >> Can you explain this a little bit more detailed? Maybe you have a >> configuration example. >> >> >> >> Regards, >> Florian >> >> >> >> *Von:* Eric Wittmann >> *Gesendet:* Friday, 30 November 2018 14:22 >> *An:* Volk, Florian >> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >> Benjamin ; Gebert, Alfred < >> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >> >> >> >> Are both gateways using the same persistent storage? Each gateway would >> need separate, independent persistence otherwise they will behave as a >> single "logical" gateway. >> >> >> >> -Eric >> >> >> >> >> >> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < >> Florian.Volk at scheer-group.com> wrote: >> >> Hello together, >> >> >> >> I was interested in this and made a short test in my loacal environment >> and I am able to reproduce this. >> >> I created a ticket on github for this ( >> https://github.com/apiman/apiman/issues/711). We may can fix this >> shortly. >> >> >> >> Regards, >> >> Florian >> >> >> >> *Von:* apiman-user-bounces at lists.jboss.org < >> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang >> *Gesendet:* Friday, 30 November 2018 03:28 >> *An:* marc.savy at redhat.com >> *Cc:* apiman-user at lists.jboss.org >> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway >> >> >> >> Dear Marc >> >> >> >> Yes I untick another gateway however request towards both gateways still >> works. >> >> Besides I tried to publish API via admin REST API (post api version then >> put gateway info), both gateways forwards request too. >> >> Before filing a bug is there any apigw setting I shall check? (such as >> parameter in apiman.properties or etc...) >> >> Thanks for your help. >> >> Regards >> >> Marc Savy ? 2018?11?21? ?? ??9:35??? >> >> Apologies for the terribly slow reply. We've had so much spam I've missed >> legitimate emails like this. >> >> >> >> Did you explicitly untick the other gateway? Was this via the UI or the >> API? >> >> >> >> Did you resolve this issue? If not, please file a bug: >> https://github.com/apiman/apiman/issues >> >> >> >> On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: >> >> Dears >> >> >> >> I had set up 2 gateways. >> >> When I new an API, I have to choose which gateway to publish. (select >> list at Gateway section in the implementation tab). >> >> However after creating a client app and contract for test, I found >> request via another gateway still works. >> >> (I guest when publishing to gateway 1 and request via gateway 2 shall >> fail) >> >> Am I misunderstanding or I miss some settings to make it work? >> >> Thanks >> >> _______________________________________________ >> 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/20181206/8e735179/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18859 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181206/8e735179/attachment-0001.png From chttl582 at gmail.com Thu Dec 13 01:54:22 2018 From: chttl582 at gmail.com (Jon Huang) Date: Thu, 13 Dec 2018 14:54:22 +0800 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Dear Eric I spent some time to track this issue. First I hit the status API (GATEWAY_API_URL/system/status) and got following response: { "id": "apiman-gateway-api", "name": "API Gateway REST API", "description": "The API Gateway REST API is used by the API Manager to publish APIs and register clients. You can use it directly if you wish, but if you are utilizing the API Manager then it's probably best to avoid invoking this API directly.", "version": "1.5.2-SNAPSHOT", "up": true } seems OK, then I hit the register client API (PUT GATEWAY_API_URL/clients) to retrieve further information, which returned an ApiNotFoundException. After reviewing the payload, I found the register client API sent every contract info to the gateway endpoint. (ex: contract A & B to Gateway 2, refer to following diagram) { "organizationId": "ORG", "clientId": "CLIENT", "version": "1.0", "apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2", "contracts": [{ "apiOrgId": "ORG", "apiId": "API1", "apiVersion": "1.0", "plan": "plan", "policies": [] }, { "apiOrgId": "ORG", "apiId": "API2", "apiVersion": "1.0", "plan": "plan", "policies": [] } ] } [image: image.png] So if there is an contract's which its API publishing to another gateway leads to 404 not found exception. (ex: contract A info sent to Gateway 2) Maybe filtering the register client API payload or preventing API manager UI from creating contract between APIs with different gateways can solve this issue. (or is there any other solution?) Thanks. Eric Wittmann ? 2018?12?6? ?? ??9:47??? > Your diagram looks exactly right. I don't know why you are getting a 404 > error when trying to register the client. My best guess is that your > Gateway 2 configuration is actually incorrect and that the "Test Gateway" > function is returning a false positive somehow. Can you post the > configuration settings you are using for *BOTH* of your Gateways? (I > assume you can successfully publish an API to Gateway 1). > > You should be able to manually confirm your Gateway settings using e.g. > curl or postman. There is an endpoint on the Gateway API that you can hit: > > GATEWAY_API_URL/system/status > > You'll need to provide auth info for this to work, but it will return a > JSON response like this: > > { > "id": "xyz", > "name": "Apiman Gateway API", > "description": "... something here ...", > "version": "x.y.z", > "up": true > } > > The UI should be checking that endpoint when you click the "Test Gateway" > button, but perhaps there's a bug in that. > > If the above endpoint can be hit and verified, then I'm at a complete loss > as to why you'd be getting a 404 when trying to publish! The implication > is that the Gateway API endpoint that the UI is attempting to use is > missing. But if /system/status can be found, then everything else should > be available too! > > @Marc Savy - any thoughts on this? > > -Eric > > > On Thu, Dec 6, 2018 at 3:02 AM Jon Huang wrote: > >> Dear Eric >> >> Thanks for your explanation. >> I tried to deploy another gateway with a new storage(Elasticsearch) and >> configure API to publish on the new one. (API manager version 1.5.1) >> However when I tried to create a contract between API and client apps >> then re-register client apps, error happened. >> It seems API manager fails to connect to gateway2. (But UI-> Manage >> Gateways -> Edit Gateway -> Test Gateway returns *Gateway Configuration >> Valid*) >> (io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed >> to register client.) >> I put detail log in attachment if you are interested. >> Thanks >> >> simple diagram for my deployment test. >> [image: image.png] >> >> >> Volk, Florian ? 2018?11?30? ?? ??10:24??? >> >>> Hi Eric, >>> >>> >>> >>> thanks for this detailed answer J >>> >>> This is quite interesting. We didn?t expected this behavior. Maybe it >>> would be good to place this in the documentation, maybe with this picture ;) >>> >>> >>> >>> But this raises a few new questions for us. I try to explain: >>> >>> >>> >>> ? Do we need for *alternate* setup two UIs if we don?t want to >>> use the REST interface or CLI-Tool? >>> >>> o One for ?Gateway Alpha? and one for ?Gateway Beta?? >>> >>> o Because I think you can only connect one elasticseach instance with >>> the UI. Am I right on this? >>> >>> o What about the metrics in this use case ? leads to two UIs? >>> >>> >>> >>> ? For the ?one logical gateway? >>> >>> o If I understand you correctly this would mean that I also have to >>> configure only one gateway in my UI and can add X more without adding them >>> into the UI. >>> I just have to point them against the same elasticsearch instance. >>> >>> I also post this mail to the github issue, so we can stay within the >>> mailinglist. >>> >>> >>> >>> Thanks again, >>> >>> Florian >>> >>> >>> >>> >>> >>> *Von:* Eric Wittmann >>> *Gesendet:* Friday, 30 November 2018 14:57 >>> *An:* Volk, Florian >>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>> Benjamin ; Gebert, Alfred < >>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >>> >>> >>> >>> Sure no problem. The typical use-case for having multiple Gateway nodes >>> is to scale the gateway layer horizontally and then put a load balancer in >>> front of them. So for example you might start up 5 apiman gateway >>> instances and configure them all to use the same Elasticsearch instance for >>> persistence (i.e. where to store configuration info like which APIs have >>> been published). In this use-case, every gateway instance has the same set >>> of APIs "published" to it. You can publish an API from the UI/manager to >>> **any** of the gateway instances and they will all know about that API. >>> This is the "Single Logical Gateway" use-case -- the UI/manager and all >>> consumers don't know or care how many gateway nodes there are - there could >>> be 1 node, or there could be 100. It behaves the same logically. >>> >>> >>> >>> An **alternate** use case for having multiple gateways is when you >>> actually want different APIs to be deployed to different gateways. So >>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, >>> B, and C. Then you have Gateway Beta which you want to proxy traffic to >>> APIs C, D, and E. In that case, consumer traffic MUST be routed through >>> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be >>> routed through Gateway Beta to access APIs D and E. Finally, consumer >>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order >>> to access API C. Think of this as the "Two Logical Gateways" use-case. >>> >>> >>> >>> In order to achieve the "Two Logical Gateways" use-case, you will need >>> **two** separate persistence stores (Elasticsearch instances). Then you >>> configure Gateway Alpha to use persistence store #1 and configure Gateway >>> Beta to use persistence store #2. >>> >>> >>> >>> Note that you can have multiple gateway nodes for EACH of the two >>> logical gateways. So for example you could have 5 gateway instances all >>> pointing to persistence store #1 - these 5 nodes would make up a single >>> logical gateway called "Gateway Alpha". Then you could have 10 gateway >>> instances all pointing to persistence store #2 - and these would be a >>> single logical gateway called "Gateway Beta". >>> >>> >>> >>> Here is a diagram of what the architecture might look like: >>> >>> >>> >>> [image: image.png] >>> >>> >>> >>> >>> >>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < >>> Florian.Volk at scheer-group.com> wrote: >>> >>> Hi Eric, >>> >>> >>> >>> now I?m confused. We use Elasticsearch as backend. If I understand you >>> correctly it would mean that we have to setup an Elasticsearch instance for >>> each gateway? >>> >>> On the other point, if the gateways operate as logical unit, why is >>> there a configuration option in the ui? >>> >>> >>> >>> Can you explain this a little bit more detailed? Maybe you have a >>> configuration example. >>> >>> >>> >>> Regards, >>> Florian >>> >>> >>> >>> *Von:* Eric Wittmann >>> *Gesendet:* Friday, 30 November 2018 14:22 >>> *An:* Volk, Florian >>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>> Benjamin ; Gebert, Alfred < >>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >>> >>> >>> >>> Are both gateways using the same persistent storage? Each gateway would >>> need separate, independent persistence otherwise they will behave as a >>> single "logical" gateway. >>> >>> >>> >>> -Eric >>> >>> >>> >>> >>> >>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < >>> Florian.Volk at scheer-group.com> wrote: >>> >>> Hello together, >>> >>> >>> >>> I was interested in this and made a short test in my loacal environment >>> and I am able to reproduce this. >>> >>> I created a ticket on github for this ( >>> https://github.com/apiman/apiman/issues/711). We may can fix this >>> shortly. >>> >>> >>> >>> Regards, >>> >>> Florian >>> >>> >>> >>> *Von:* apiman-user-bounces at lists.jboss.org < >>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang >>> *Gesendet:* Friday, 30 November 2018 03:28 >>> *An:* marc.savy at redhat.com >>> *Cc:* apiman-user at lists.jboss.org >>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway >>> >>> >>> >>> Dear Marc >>> >>> >>> >>> Yes I untick another gateway however request towards both gateways still >>> works. >>> >>> Besides I tried to publish API via admin REST API (post api version then >>> put gateway info), both gateways forwards request too. >>> >>> Before filing a bug is there any apigw setting I shall check? (such as >>> parameter in apiman.properties or etc...) >>> >>> Thanks for your help. >>> >>> Regards >>> >>> Marc Savy ? 2018?11?21? ?? ??9:35??? >>> >>> Apologies for the terribly slow reply. We've had so much spam I've >>> missed legitimate emails like this. >>> >>> >>> >>> Did you explicitly untick the other gateway? Was this via the UI or the >>> API? >>> >>> >>> >>> Did you resolve this issue? If not, please file a bug: >>> https://github.com/apiman/apiman/issues >>> >>> >>> >>> On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: >>> >>> Dears >>> >>> >>> >>> I had set up 2 gateways. >>> >>> When I new an API, I have to choose which gateway to publish. (select >>> list at Gateway section in the implementation tab). >>> >>> However after creating a client app and contract for test, I found >>> request via another gateway still works. >>> >>> (I guest when publishing to gateway 1 and request via gateway 2 shall >>> fail) >>> >>> Am I misunderstanding or I miss some settings to make it work? >>> >>> Thanks >>> >>> _______________________________________________ >>> 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/20181213/a0547e74/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18859 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181213/a0547e74/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32122 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181213/a0547e74/attachment-0003.png From eric.wittmann at redhat.com Thu Dec 13 15:29:59 2018 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 13 Dec 2018 15:29:59 -0500 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Very interesting, thanks Jon. So if I understand correctly, the problem is that the Client has a contract for API1 (published to GW1) and a contract for API2 (published to GW2). And so when registering a client, we're trying to send Contracts for APIs that don't exist on the GW. So yeah, filtering the list of Contracts during registration makes sense. We should file this as a bug in Apiman (on GitHub). Would you be willing to do that? https://github.com/apiman/apiman/issues -Eric On Thu, Dec 13, 2018 at 1:54 AM Jon Huang wrote: > Dear Eric > > I spent some time to track this issue. > First I hit the status API (GATEWAY_API_URL/system/status) and got > following response: > { > "id": "apiman-gateway-api", > "name": "API Gateway REST API", > "description": "The API Gateway REST API is used by the API Manager to > publish APIs and register clients. You can use it directly if you wish, > but if you are utilizing the API Manager then it's probably best to avoid > invoking this API directly.", > "version": "1.5.2-SNAPSHOT", > "up": true > } > seems OK, then I hit the register client API (PUT GATEWAY_API_URL/clients) > to retrieve further information, which returned an ApiNotFoundException. > After reviewing the payload, I found the register client API sent every > contract info to the gateway endpoint. (ex: contract A & B to Gateway 2, > refer to following diagram) > { > "organizationId": "ORG", > "clientId": "CLIENT", > "version": "1.0", > "apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2", > "contracts": [{ > "apiOrgId": "ORG", > "apiId": "API1", > "apiVersion": "1.0", > "plan": "plan", > "policies": [] > }, { > "apiOrgId": "ORG", > "apiId": "API2", > "apiVersion": "1.0", > "plan": "plan", > "policies": [] > } > ] > } > > [image: image.png] > > So if there is an contract's which its API publishing to another gateway > leads to 404 not found exception. (ex: contract A info sent to Gateway 2) > Maybe filtering the register client API payload or preventing API manager > UI from creating contract between APIs with different gateways can solve > this issue. (or is there any other solution?) > Thanks. > > > Eric Wittmann ? 2018?12?6? ?? ??9:47??? > >> Your diagram looks exactly right. I don't know why you are getting a 404 >> error when trying to register the client. My best guess is that your >> Gateway 2 configuration is actually incorrect and that the "Test Gateway" >> function is returning a false positive somehow. Can you post the >> configuration settings you are using for *BOTH* of your Gateways? (I >> assume you can successfully publish an API to Gateway 1). >> >> You should be able to manually confirm your Gateway settings using e.g. >> curl or postman. There is an endpoint on the Gateway API that you can hit: >> >> GATEWAY_API_URL/system/status >> >> You'll need to provide auth info for this to work, but it will return a >> JSON response like this: >> >> { >> "id": "xyz", >> "name": "Apiman Gateway API", >> "description": "... something here ...", >> "version": "x.y.z", >> "up": true >> } >> >> The UI should be checking that endpoint when you click the "Test Gateway" >> button, but perhaps there's a bug in that. >> >> If the above endpoint can be hit and verified, then I'm at a complete >> loss as to why you'd be getting a 404 when trying to publish! The >> implication is that the Gateway API endpoint that the UI is attempting to >> use is missing. But if /system/status can be found, then everything else >> should be available too! >> >> @Marc Savy - any thoughts on this? >> >> -Eric >> >> >> On Thu, Dec 6, 2018 at 3:02 AM Jon Huang wrote: >> >>> Dear Eric >>> >>> Thanks for your explanation. >>> I tried to deploy another gateway with a new storage(Elasticsearch) and >>> configure API to publish on the new one. (API manager version 1.5.1) >>> However when I tried to create a contract between API and client apps >>> then re-register client apps, error happened. >>> It seems API manager fails to connect to gateway2. (But UI-> Manage >>> Gateways -> Edit Gateway -> Test Gateway returns *Gateway Configuration >>> Valid*) >>> (io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed >>> to register client.) >>> I put detail log in attachment if you are interested. >>> Thanks >>> >>> simple diagram for my deployment test. >>> [image: image.png] >>> >>> >>> Volk, Florian ? 2018?11?30? ?? >>> ??10:24??? >>> >>>> Hi Eric, >>>> >>>> >>>> >>>> thanks for this detailed answer J >>>> >>>> This is quite interesting. We didn?t expected this behavior. Maybe it >>>> would be good to place this in the documentation, maybe with this picture ;) >>>> >>>> >>>> >>>> But this raises a few new questions for us. I try to explain: >>>> >>>> >>>> >>>> ? Do we need for *alternate* setup two UIs if we don?t want to >>>> use the REST interface or CLI-Tool? >>>> >>>> o One for ?Gateway Alpha? and one for ?Gateway Beta?? >>>> >>>> o Because I think you can only connect one elasticseach instance >>>> with the UI. Am I right on this? >>>> >>>> o What about the metrics in this use case ? leads to two UIs? >>>> >>>> >>>> >>>> ? For the ?one logical gateway? >>>> >>>> o If I understand you correctly this would mean that I also have to >>>> configure only one gateway in my UI and can add X more without adding them >>>> into the UI. >>>> I just have to point them against the same elasticsearch instance. >>>> >>>> I also post this mail to the github issue, so we can stay within the >>>> mailinglist. >>>> >>>> >>>> >>>> Thanks again, >>>> >>>> Florian >>>> >>>> >>>> >>>> >>>> >>>> *Von:* Eric Wittmann >>>> *Gesendet:* Friday, 30 November 2018 14:57 >>>> *An:* Volk, Florian >>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>> Benjamin ; Gebert, Alfred < >>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >>>> >>>> >>>> >>>> Sure no problem. The typical use-case for having multiple Gateway >>>> nodes is to scale the gateway layer horizontally and then put a load >>>> balancer in front of them. So for example you might start up 5 apiman >>>> gateway instances and configure them all to use the same Elasticsearch >>>> instance for persistence (i.e. where to store configuration info like which >>>> APIs have been published). In this use-case, every gateway instance has >>>> the same set of APIs "published" to it. You can publish an API from the >>>> UI/manager to **any** of the gateway instances and they will all know about >>>> that API. This is the "Single Logical Gateway" use-case -- the UI/manager >>>> and all consumers don't know or care how many gateway nodes there are - >>>> there could be 1 node, or there could be 100. It behaves the same >>>> logically. >>>> >>>> >>>> >>>> An **alternate** use case for having multiple gateways is when you >>>> actually want different APIs to be deployed to different gateways. So >>>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, >>>> B, and C. Then you have Gateway Beta which you want to proxy traffic to >>>> APIs C, D, and E. In that case, consumer traffic MUST be routed through >>>> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be >>>> routed through Gateway Beta to access APIs D and E. Finally, consumer >>>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order >>>> to access API C. Think of this as the "Two Logical Gateways" use-case. >>>> >>>> >>>> >>>> In order to achieve the "Two Logical Gateways" use-case, you will need >>>> **two** separate persistence stores (Elasticsearch instances). Then you >>>> configure Gateway Alpha to use persistence store #1 and configure Gateway >>>> Beta to use persistence store #2. >>>> >>>> >>>> >>>> Note that you can have multiple gateway nodes for EACH of the two >>>> logical gateways. So for example you could have 5 gateway instances all >>>> pointing to persistence store #1 - these 5 nodes would make up a single >>>> logical gateway called "Gateway Alpha". Then you could have 10 gateway >>>> instances all pointing to persistence store #2 - and these would be a >>>> single logical gateway called "Gateway Beta". >>>> >>>> >>>> >>>> Here is a diagram of what the architecture might look like: >>>> >>>> >>>> >>>> [image: image.png] >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < >>>> Florian.Volk at scheer-group.com> wrote: >>>> >>>> Hi Eric, >>>> >>>> >>>> >>>> now I?m confused. We use Elasticsearch as backend. If I understand you >>>> correctly it would mean that we have to setup an Elasticsearch instance for >>>> each gateway? >>>> >>>> On the other point, if the gateways operate as logical unit, why is >>>> there a configuration option in the ui? >>>> >>>> >>>> >>>> Can you explain this a little bit more detailed? Maybe you have a >>>> configuration example. >>>> >>>> >>>> >>>> Regards, >>>> Florian >>>> >>>> >>>> >>>> *Von:* Eric Wittmann >>>> *Gesendet:* Friday, 30 November 2018 14:22 >>>> *An:* Volk, Florian >>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>> Benjamin ; Gebert, Alfred < >>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway >>>> >>>> >>>> >>>> Are both gateways using the same persistent storage? Each gateway >>>> would need separate, independent persistence otherwise they will behave as >>>> a single "logical" gateway. >>>> >>>> >>>> >>>> -Eric >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < >>>> Florian.Volk at scheer-group.com> wrote: >>>> >>>> Hello together, >>>> >>>> >>>> >>>> I was interested in this and made a short test in my loacal environment >>>> and I am able to reproduce this. >>>> >>>> I created a ticket on github for this ( >>>> https://github.com/apiman/apiman/issues/711). We may can fix this >>>> shortly. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Florian >>>> >>>> >>>> >>>> *Von:* apiman-user-bounces at lists.jboss.org < >>>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang >>>> *Gesendet:* Friday, 30 November 2018 03:28 >>>> *An:* marc.savy at redhat.com >>>> *Cc:* apiman-user at lists.jboss.org >>>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway >>>> >>>> >>>> >>>> Dear Marc >>>> >>>> >>>> >>>> Yes I untick another gateway however request towards both gateways >>>> still works. >>>> >>>> Besides I tried to publish API via admin REST API (post api version >>>> then put gateway info), both gateways forwards request too. >>>> >>>> Before filing a bug is there any apigw setting I shall check? (such as >>>> parameter in apiman.properties or etc...) >>>> >>>> Thanks for your help. >>>> >>>> Regards >>>> >>>> Marc Savy ? 2018?11?21? ?? ??9:35??? >>>> >>>> Apologies for the terribly slow reply. We've had so much spam I've >>>> missed legitimate emails like this. >>>> >>>> >>>> >>>> Did you explicitly untick the other gateway? Was this via the UI or the >>>> API? >>>> >>>> >>>> >>>> Did you resolve this issue? If not, please file a bug: >>>> https://github.com/apiman/apiman/issues >>>> >>>> >>>> >>>> On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: >>>> >>>> Dears >>>> >>>> >>>> >>>> I had set up 2 gateways. >>>> >>>> When I new an API, I have to choose which gateway to publish. (select >>>> list at Gateway section in the implementation tab). >>>> >>>> However after creating a client app and contract for test, I found >>>> request via another gateway still works. >>>> >>>> (I guest when publishing to gateway 1 and request via gateway 2 shall >>>> fail) >>>> >>>> Am I misunderstanding or I miss some settings to make it work? >>>> >>>> Thanks >>>> >>>> _______________________________________________ >>>> 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/20181213/df9d3c66/attachment-0001.html From chttl582 at gmail.com Fri Dec 14 04:34:38 2018 From: chttl582 at gmail.com (Jon Huang) Date: Fri, 14 Dec 2018 17:34:38 +0800 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Dear Eric Yes, I think it's the root cause. and sure, I've posted the issue on GitHub. Thanks Eric Wittmann ? 2018?12?14? ?? ??4:30??? > Very interesting, thanks Jon. So if I understand correctly, the problem > is that the Client has a contract for API1 (published to GW1) and a > contract for API2 (published to GW2). And so when registering a client, > we're trying to send Contracts for APIs that don't exist on the GW. So > yeah, filtering the list of Contracts during registration makes sense. We > should file this as a bug in Apiman (on GitHub). Would you be willing to > do that? > > https://github.com/apiman/apiman/issues > > -Eric > > > On Thu, Dec 13, 2018 at 1:54 AM Jon Huang wrote: > >> Dear Eric >> >> I spent some time to track this issue. >> First I hit the status API (GATEWAY_API_URL/system/status) and got >> following response: >> { >> "id": "apiman-gateway-api", >> "name": "API Gateway REST API", >> "description": "The API Gateway REST API is used by the API Manager >> to publish APIs and register clients. You can use it directly if you wish, >> but if you are utilizing the API Manager then it's probably best to avoid >> invoking this API directly.", >> "version": "1.5.2-SNAPSHOT", >> "up": true >> } >> seems OK, then I hit the register client API (PUT GATEWAY_API_URL >> /clients) to retrieve further information, which returned an >> ApiNotFoundException. >> After reviewing the payload, I found the register client API sent every >> contract info to the gateway endpoint. (ex: contract A & B to Gateway 2, >> refer to following diagram) >> { >> "organizationId": "ORG", >> "clientId": "CLIENT", >> "version": "1.0", >> "apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2", >> "contracts": [{ >> "apiOrgId": "ORG", >> "apiId": "API1", >> "apiVersion": "1.0", >> "plan": "plan", >> "policies": [] >> }, { >> "apiOrgId": "ORG", >> "apiId": "API2", >> "apiVersion": "1.0", >> "plan": "plan", >> "policies": [] >> } >> ] >> } >> >> [image: image.png] >> >> So if there is an contract's which its API publishing to another gateway >> leads to 404 not found exception. (ex: contract A info sent to Gateway 2) >> Maybe filtering the register client API payload or preventing API manager >> UI from creating contract between APIs with different gateways can solve >> this issue. (or is there any other solution?) >> Thanks. >> >> >> Eric Wittmann ? 2018?12?6? ?? ??9:47??? >> >>> Your diagram looks exactly right. I don't know why you are getting a >>> 404 error when trying to register the client. My best guess is that your >>> Gateway 2 configuration is actually incorrect and that the "Test Gateway" >>> function is returning a false positive somehow. Can you post the >>> configuration settings you are using for *BOTH* of your Gateways? (I >>> assume you can successfully publish an API to Gateway 1). >>> >>> You should be able to manually confirm your Gateway settings using e.g. >>> curl or postman. There is an endpoint on the Gateway API that you can hit: >>> >>> GATEWAY_API_URL/system/status >>> >>> You'll need to provide auth info for this to work, but it will return a >>> JSON response like this: >>> >>> { >>> "id": "xyz", >>> "name": "Apiman Gateway API", >>> "description": "... something here ...", >>> "version": "x.y.z", >>> "up": true >>> } >>> >>> The UI should be checking that endpoint when you click the "Test >>> Gateway" button, but perhaps there's a bug in that. >>> >>> If the above endpoint can be hit and verified, then I'm at a complete >>> loss as to why you'd be getting a 404 when trying to publish! The >>> implication is that the Gateway API endpoint that the UI is attempting to >>> use is missing. But if /system/status can be found, then everything else >>> should be available too! >>> >>> @Marc Savy - any thoughts on this? >>> >>> -Eric >>> >>> >>> On Thu, Dec 6, 2018 at 3:02 AM Jon Huang wrote: >>> >>>> Dear Eric >>>> >>>> Thanks for your explanation. >>>> I tried to deploy another gateway with a new storage(Elasticsearch) and >>>> configure API to publish on the new one. (API manager version 1.5.1) >>>> However when I tried to create a contract between API and client apps >>>> then re-register client apps, error happened. >>>> It seems API manager fails to connect to gateway2. (But UI-> Manage >>>> Gateways -> Edit Gateway -> Test Gateway returns *Gateway >>>> Configuration Valid*) >>>> (io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>> Failed to register client.) >>>> I put detail log in attachment if you are interested. >>>> Thanks >>>> >>>> simple diagram for my deployment test. >>>> [image: image.png] >>>> >>>> >>>> Volk, Florian ? 2018?11?30? ?? >>>> ??10:24??? >>>> >>>>> Hi Eric, >>>>> >>>>> >>>>> >>>>> thanks for this detailed answer J >>>>> >>>>> This is quite interesting. We didn?t expected this behavior. Maybe it >>>>> would be good to place this in the documentation, maybe with this picture ;) >>>>> >>>>> >>>>> >>>>> But this raises a few new questions for us. I try to explain: >>>>> >>>>> >>>>> >>>>> ? Do we need for *alternate* setup two UIs if we don?t want >>>>> to use the REST interface or CLI-Tool? >>>>> >>>>> o One for ?Gateway Alpha? and one for ?Gateway Beta?? >>>>> >>>>> o Because I think you can only connect one elasticseach instance >>>>> with the UI. Am I right on this? >>>>> >>>>> o What about the metrics in this use case ? leads to two UIs? >>>>> >>>>> >>>>> >>>>> ? For the ?one logical gateway? >>>>> >>>>> o If I understand you correctly this would mean that I also have to >>>>> configure only one gateway in my UI and can add X more without adding them >>>>> into the UI. >>>>> I just have to point them against the same elasticsearch instance. >>>>> >>>>> I also post this mail to the github issue, so we can stay within the >>>>> mailinglist. >>>>> >>>>> >>>>> >>>>> Thanks again, >>>>> >>>>> Florian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Von:* Eric Wittmann >>>>> *Gesendet:* Friday, 30 November 2018 14:57 >>>>> *An:* Volk, Florian >>>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>>> Benjamin ; Gebert, Alfred < >>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific >>>>> gateway >>>>> >>>>> >>>>> >>>>> Sure no problem. The typical use-case for having multiple Gateway >>>>> nodes is to scale the gateway layer horizontally and then put a load >>>>> balancer in front of them. So for example you might start up 5 apiman >>>>> gateway instances and configure them all to use the same Elasticsearch >>>>> instance for persistence (i.e. where to store configuration info like which >>>>> APIs have been published). In this use-case, every gateway instance has >>>>> the same set of APIs "published" to it. You can publish an API from the >>>>> UI/manager to **any** of the gateway instances and they will all know about >>>>> that API. This is the "Single Logical Gateway" use-case -- the UI/manager >>>>> and all consumers don't know or care how many gateway nodes there are - >>>>> there could be 1 node, or there could be 100. It behaves the same >>>>> logically. >>>>> >>>>> >>>>> >>>>> An **alternate** use case for having multiple gateways is when you >>>>> actually want different APIs to be deployed to different gateways. So >>>>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, >>>>> B, and C. Then you have Gateway Beta which you want to proxy traffic to >>>>> APIs C, D, and E. In that case, consumer traffic MUST be routed through >>>>> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be >>>>> routed through Gateway Beta to access APIs D and E. Finally, consumer >>>>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order >>>>> to access API C. Think of this as the "Two Logical Gateways" use-case. >>>>> >>>>> >>>>> >>>>> In order to achieve the "Two Logical Gateways" use-case, you will need >>>>> **two** separate persistence stores (Elasticsearch instances). Then you >>>>> configure Gateway Alpha to use persistence store #1 and configure Gateway >>>>> Beta to use persistence store #2. >>>>> >>>>> >>>>> >>>>> Note that you can have multiple gateway nodes for EACH of the two >>>>> logical gateways. So for example you could have 5 gateway instances all >>>>> pointing to persistence store #1 - these 5 nodes would make up a single >>>>> logical gateway called "Gateway Alpha". Then you could have 10 gateway >>>>> instances all pointing to persistence store #2 - and these would be a >>>>> single logical gateway called "Gateway Beta". >>>>> >>>>> >>>>> >>>>> Here is a diagram of what the architecture might look like: >>>>> >>>>> >>>>> >>>>> [image: image.png] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < >>>>> Florian.Volk at scheer-group.com> wrote: >>>>> >>>>> Hi Eric, >>>>> >>>>> >>>>> >>>>> now I?m confused. We use Elasticsearch as backend. If I understand you >>>>> correctly it would mean that we have to setup an Elasticsearch instance for >>>>> each gateway? >>>>> >>>>> On the other point, if the gateways operate as logical unit, why is >>>>> there a configuration option in the ui? >>>>> >>>>> >>>>> >>>>> Can you explain this a little bit more detailed? Maybe you have a >>>>> configuration example. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Florian >>>>> >>>>> >>>>> >>>>> *Von:* Eric Wittmann >>>>> *Gesendet:* Friday, 30 November 2018 14:22 >>>>> *An:* Volk, Florian >>>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>>> Benjamin ; Gebert, Alfred < >>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific >>>>> gateway >>>>> >>>>> >>>>> >>>>> Are both gateways using the same persistent storage? Each gateway >>>>> would need separate, independent persistence otherwise they will behave as >>>>> a single "logical" gateway. >>>>> >>>>> >>>>> >>>>> -Eric >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < >>>>> Florian.Volk at scheer-group.com> wrote: >>>>> >>>>> Hello together, >>>>> >>>>> >>>>> >>>>> I was interested in this and made a short test in my loacal >>>>> environment and I am able to reproduce this. >>>>> >>>>> I created a ticket on github for this ( >>>>> https://github.com/apiman/apiman/issues/711). We may can fix this >>>>> shortly. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Florian >>>>> >>>>> >>>>> >>>>> *Von:* apiman-user-bounces at lists.jboss.org < >>>>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang >>>>> *Gesendet:* Friday, 30 November 2018 03:28 >>>>> *An:* marc.savy at redhat.com >>>>> *Cc:* apiman-user at lists.jboss.org >>>>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway >>>>> >>>>> >>>>> >>>>> Dear Marc >>>>> >>>>> >>>>> >>>>> Yes I untick another gateway however request towards both gateways >>>>> still works. >>>>> >>>>> Besides I tried to publish API via admin REST API (post api version >>>>> then put gateway info), both gateways forwards request too. >>>>> >>>>> Before filing a bug is there any apigw setting I shall check? (such as >>>>> parameter in apiman.properties or etc...) >>>>> >>>>> Thanks for your help. >>>>> >>>>> Regards >>>>> >>>>> Marc Savy ? 2018?11?21? ?? ??9:35??? >>>>> >>>>> Apologies for the terribly slow reply. We've had so much spam I've >>>>> missed legitimate emails like this. >>>>> >>>>> >>>>> >>>>> Did you explicitly untick the other gateway? Was this via the UI or >>>>> the API? >>>>> >>>>> >>>>> >>>>> Did you resolve this issue? If not, please file a bug: >>>>> https://github.com/apiman/apiman/issues >>>>> >>>>> >>>>> >>>>> On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: >>>>> >>>>> Dears >>>>> >>>>> >>>>> >>>>> I had set up 2 gateways. >>>>> >>>>> When I new an API, I have to choose which gateway to publish. (select >>>>> list at Gateway section in the implementation tab). >>>>> >>>>> However after creating a client app and contract for test, I found >>>>> request via another gateway still works. >>>>> >>>>> (I guest when publishing to gateway 1 and request via gateway 2 shall >>>>> fail) >>>>> >>>>> Am I misunderstanding or I miss some settings to make it work? >>>>> >>>>> Thanks >>>>> >>>>> _______________________________________________ >>>>> 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/20181214/0f97be7a/attachment-0001.html From renalexster at gmail.com Mon Dec 17 14:05:42 2018 From: renalexster at gmail.com (Renato Barros) Date: Mon, 17 Dec 2018 16:05:42 -0300 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method Message-ID: Hello all, I'm getting an error with *Access-Control-Request-Method* Header in my APIs. I posted details in StackOverflow . Please, someone could help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181217/8a6b5b01/attachment.html From marc.savy at redhat.com Tue Dec 18 03:49:57 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 18 Dec 2018 08:49:57 +0000 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: I'm not sure why your browser isn't rendering it, but there should be a list in the Access-Control-Allow-Origin section that would allow you to add an entry such as "*" or "foo.com". What is your setup? On Mon, 17 Dec 2018 at 19:10, Renato Barros wrote: > Hello all, > > I'm getting an error with *Access-Control-Request-Method* Header in my > APIs. > > I posted details in StackOverflow > > . > > Please, someone could help me? > _______________________________________________ > 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/20181218/d80cd891/attachment.html From renalexster at gmail.com Tue Dec 18 07:34:57 2018 From: renalexster at gmail.com (Renato Barros) Date: Tue, 18 Dec 2018 09:34:57 -0300 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: Hi Marc, I've just updated the image with details. The Access-Control-Allow-Origin already had "*" as value. [image: image.png] On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: > I'm not sure why your browser isn't rendering it, but there should be a > list in the Access-Control-Allow-Origin section that would allow you to add > an entry such as "*" or "foo.com". > > What is your setup? > > On Mon, 17 Dec 2018 at 19:10, Renato Barros wrote: > >> Hello all, >> >> I'm getting an error with *Access-Control-Request-Method* Header in my >> APIs. >> >> I posted details in StackOverflow >> >> . >> >> Please, someone could help me? >> _______________________________________________ >> 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/20181218/08441113/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 154841 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/08441113/attachment-0001.png From marc.savy at redhat.com Tue Dec 18 07:40:34 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 18 Dec 2018 12:40:34 +0000 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: I think your issue might be the way that you're formulating your request. In order to issue a valid CORS request, you must set your origin header. You should probably try that first. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin e.g. curl ... -H "Origin: mymachine.local" When using a browser, this is usually issued on your behalf. But, if you're using curl, it won't be. On Tue, 18 Dec 2018 at 12:35, Renato Barros wrote: > Hi Marc, > > I've just updated the image with details. The Access-Control-Allow-Origin > already had "*" as value. > > [image: image.png] > > On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: > >> I'm not sure why your browser isn't rendering it, but there should be a >> list in the Access-Control-Allow-Origin section that would allow you to add >> an entry such as "*" or "foo.com". >> >> What is your setup? >> >> On Mon, 17 Dec 2018 at 19:10, Renato Barros >> wrote: >> >>> Hello all, >>> >>> I'm getting an error with *Access-Control-Request-Method* Header in my >>> APIs. >>> >>> I posted details in StackOverflow >>> >>> . >>> >>> Please, someone could help me? >>> _______________________________________________ >>> 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/20181218/75f400cb/attachment.html From renalexster at gmail.com Tue Dec 18 07:58:50 2018 From: renalexster at gmail.com (Renato Barros) Date: Tue, 18 Dec 2018 09:58:50 -0300 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: Hello Marc, I don't think the problem is associated with *Access-Control-Allow-Origin*. Below there are two requests using Restlet Client, the first one works without the *Header Access-Controle-Request-Method*, the second only adding this Header gets fail. [image: image.png] On Tue, 18 Dec 2018 at 09:40, Marc Savy wrote: > I think your issue might be the way that you're formulating your request. > > In order to issue a valid CORS request, you must set your origin header. > You should probably try that first. > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin > > e.g. curl ... -H "Origin: mymachine.local" > > When using a browser, this is usually issued on your behalf. But, if > you're using curl, it won't be. > > > On Tue, 18 Dec 2018 at 12:35, Renato Barros wrote: > >> Hi Marc, >> >> I've just updated the image with details. The Access-Control-Allow-Origin >> already had "*" as value. >> >> [image: image.png] >> >> On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: >> >>> I'm not sure why your browser isn't rendering it, but there should be a >>> list in the Access-Control-Allow-Origin section that would allow you to add >>> an entry such as "*" or "foo.com". >>> >>> What is your setup? >>> >>> On Mon, 17 Dec 2018 at 19:10, Renato Barros >>> wrote: >>> >>>> Hello all, >>>> >>>> I'm getting an error with *Access-Control-Request-Method* Header in my >>>> APIs. >>>> >>>> I posted details in StackOverflow >>>> >>>> . >>>> >>>> Please, someone could help me? >>>> _______________________________________________ >>>> 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/20181218/f41c7d5b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 204857 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/f41c7d5b/attachment-0001.png From eric.wittmann at redhat.com Tue Dec 18 08:44:20 2018 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 18 Dec 2018 08:44:20 -0500 Subject: [Apiman-user] [DKIM] Re: publish api to specific gateway In-Reply-To: References: <5f5fcb84c65548c99fe5a81b5f97aa3b@sgrpexc001.scheer.systems> <517bbd0247ee4e6bac5f40e1dc032fee@sgrpexc001.scheer.systems> Message-ID: Awesome, thanks for taking the time to figure all that out, Jon. -Eric On Fri, Dec 14, 2018 at 4:35 AM Jon Huang wrote: > Dear Eric > > Yes, I think it's the root cause. > and sure, I've posted the issue on GitHub. > Thanks > > Eric Wittmann ? 2018?12?14? ?? ??4:30??? > >> Very interesting, thanks Jon. So if I understand correctly, the problem >> is that the Client has a contract for API1 (published to GW1) and a >> contract for API2 (published to GW2). And so when registering a client, >> we're trying to send Contracts for APIs that don't exist on the GW. So >> yeah, filtering the list of Contracts during registration makes sense. We >> should file this as a bug in Apiman (on GitHub). Would you be willing to >> do that? >> >> https://github.com/apiman/apiman/issues >> >> -Eric >> >> >> On Thu, Dec 13, 2018 at 1:54 AM Jon Huang wrote: >> >>> Dear Eric >>> >>> I spent some time to track this issue. >>> First I hit the status API (GATEWAY_API_URL/system/status) and got >>> following response: >>> { >>> "id": "apiman-gateway-api", >>> "name": "API Gateway REST API", >>> "description": "The API Gateway REST API is used by the API Manager >>> to publish APIs and register clients. You can use it directly if you wish, >>> but if you are utilizing the API Manager then it's probably best to avoid >>> invoking this API directly.", >>> "version": "1.5.2-SNAPSHOT", >>> "up": true >>> } >>> seems OK, then I hit the register client API (PUT GATEWAY_API_URL >>> /clients) to retrieve further information, which returned an >>> ApiNotFoundException. >>> After reviewing the payload, I found the register client API sent every >>> contract info to the gateway endpoint. (ex: contract A & B to Gateway 2, >>> refer to following diagram) >>> { >>> "organizationId": "ORG", >>> "clientId": "CLIENT", >>> "version": "1.0", >>> "apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2", >>> "contracts": [{ >>> "apiOrgId": "ORG", >>> "apiId": "API1", >>> "apiVersion": "1.0", >>> "plan": "plan", >>> "policies": [] >>> }, { >>> "apiOrgId": "ORG", >>> "apiId": "API2", >>> "apiVersion": "1.0", >>> "plan": "plan", >>> "policies": [] >>> } >>> ] >>> } >>> >>> [image: image.png] >>> >>> So if there is an contract's which its API publishing to another gateway >>> leads to 404 not found exception. (ex: contract A info sent to Gateway 2) >>> Maybe filtering the register client API payload or preventing API >>> manager UI from creating contract between APIs with different gateways can >>> solve this issue. (or is there any other solution?) >>> Thanks. >>> >>> >>> Eric Wittmann ? 2018?12?6? ?? ??9:47??? >>> >>>> Your diagram looks exactly right. I don't know why you are getting a >>>> 404 error when trying to register the client. My best guess is that your >>>> Gateway 2 configuration is actually incorrect and that the "Test Gateway" >>>> function is returning a false positive somehow. Can you post the >>>> configuration settings you are using for *BOTH* of your Gateways? (I >>>> assume you can successfully publish an API to Gateway 1). >>>> >>>> You should be able to manually confirm your Gateway settings using e.g. >>>> curl or postman. There is an endpoint on the Gateway API that you can hit: >>>> >>>> GATEWAY_API_URL/system/status >>>> >>>> You'll need to provide auth info for this to work, but it will return a >>>> JSON response like this: >>>> >>>> { >>>> "id": "xyz", >>>> "name": "Apiman Gateway API", >>>> "description": "... something here ...", >>>> "version": "x.y.z", >>>> "up": true >>>> } >>>> >>>> The UI should be checking that endpoint when you click the "Test >>>> Gateway" button, but perhaps there's a bug in that. >>>> >>>> If the above endpoint can be hit and verified, then I'm at a complete >>>> loss as to why you'd be getting a 404 when trying to publish! The >>>> implication is that the Gateway API endpoint that the UI is attempting to >>>> use is missing. But if /system/status can be found, then everything else >>>> should be available too! >>>> >>>> @Marc Savy - any thoughts on this? >>>> >>>> -Eric >>>> >>>> >>>> On Thu, Dec 6, 2018 at 3:02 AM Jon Huang wrote: >>>> >>>>> Dear Eric >>>>> >>>>> Thanks for your explanation. >>>>> I tried to deploy another gateway with a new storage(Elasticsearch) >>>>> and configure API to publish on the new one. (API manager version 1.5.1) >>>>> However when I tried to create a contract between API and client apps >>>>> then re-register client apps, error happened. >>>>> It seems API manager fails to connect to gateway2. (But UI-> Manage >>>>> Gateways -> Edit Gateway -> Test Gateway returns *Gateway >>>>> Configuration Valid*) >>>>> (io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>> Failed to register client.) >>>>> I put detail log in attachment if you are interested. >>>>> Thanks >>>>> >>>>> simple diagram for my deployment test. >>>>> [image: image.png] >>>>> >>>>> >>>>> Volk, Florian ? 2018?11?30? ?? >>>>> ??10:24??? >>>>> >>>>>> Hi Eric, >>>>>> >>>>>> >>>>>> >>>>>> thanks for this detailed answer J >>>>>> >>>>>> This is quite interesting. We didn?t expected this behavior. Maybe it >>>>>> would be good to place this in the documentation, maybe with this picture ;) >>>>>> >>>>>> >>>>>> >>>>>> But this raises a few new questions for us. I try to explain: >>>>>> >>>>>> >>>>>> >>>>>> ? Do we need for *alternate* setup two UIs if we don?t want >>>>>> to use the REST interface or CLI-Tool? >>>>>> >>>>>> o One for ?Gateway Alpha? and one for ?Gateway Beta?? >>>>>> >>>>>> o Because I think you can only connect one elasticseach instance >>>>>> with the UI. Am I right on this? >>>>>> >>>>>> o What about the metrics in this use case ? leads to two UIs? >>>>>> >>>>>> >>>>>> >>>>>> ? For the ?one logical gateway? >>>>>> >>>>>> o If I understand you correctly this would mean that I also have >>>>>> to configure only one gateway in my UI and can add X more without adding >>>>>> them into the UI. >>>>>> I just have to point them against the same elasticsearch instance. >>>>>> >>>>>> I also post this mail to the github issue, so we can stay within the >>>>>> mailinglist. >>>>>> >>>>>> >>>>>> >>>>>> Thanks again, >>>>>> >>>>>> Florian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Von:* Eric Wittmann >>>>>> *Gesendet:* Friday, 30 November 2018 14:57 >>>>>> *An:* Volk, Florian >>>>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>>>> Benjamin ; Gebert, Alfred < >>>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific >>>>>> gateway >>>>>> >>>>>> >>>>>> >>>>>> Sure no problem. The typical use-case for having multiple Gateway >>>>>> nodes is to scale the gateway layer horizontally and then put a load >>>>>> balancer in front of them. So for example you might start up 5 apiman >>>>>> gateway instances and configure them all to use the same Elasticsearch >>>>>> instance for persistence (i.e. where to store configuration info like which >>>>>> APIs have been published). In this use-case, every gateway instance has >>>>>> the same set of APIs "published" to it. You can publish an API from the >>>>>> UI/manager to **any** of the gateway instances and they will all know about >>>>>> that API. This is the "Single Logical Gateway" use-case -- the UI/manager >>>>>> and all consumers don't know or care how many gateway nodes there are - >>>>>> there could be 1 node, or there could be 100. It behaves the same >>>>>> logically. >>>>>> >>>>>> >>>>>> >>>>>> An **alternate** use case for having multiple gateways is when you >>>>>> actually want different APIs to be deployed to different gateways. So >>>>>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A, >>>>>> B, and C. Then you have Gateway Beta which you want to proxy traffic to >>>>>> APIs C, D, and E. In that case, consumer traffic MUST be routed through >>>>>> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be >>>>>> routed through Gateway Beta to access APIs D and E. Finally, consumer >>>>>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order >>>>>> to access API C. Think of this as the "Two Logical Gateways" use-case. >>>>>> >>>>>> >>>>>> >>>>>> In order to achieve the "Two Logical Gateways" use-case, you will >>>>>> need **two** separate persistence stores (Elasticsearch instances). Then >>>>>> you configure Gateway Alpha to use persistence store #1 and configure >>>>>> Gateway Beta to use persistence store #2. >>>>>> >>>>>> >>>>>> >>>>>> Note that you can have multiple gateway nodes for EACH of the two >>>>>> logical gateways. So for example you could have 5 gateway instances all >>>>>> pointing to persistence store #1 - these 5 nodes would make up a single >>>>>> logical gateway called "Gateway Alpha". Then you could have 10 gateway >>>>>> instances all pointing to persistence store #2 - and these would be a >>>>>> single logical gateway called "Gateway Beta". >>>>>> >>>>>> >>>>>> >>>>>> Here is a diagram of what the architecture might look like: >>>>>> >>>>>> >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian < >>>>>> Florian.Volk at scheer-group.com> wrote: >>>>>> >>>>>> Hi Eric, >>>>>> >>>>>> >>>>>> >>>>>> now I?m confused. We use Elasticsearch as backend. If I understand >>>>>> you correctly it would mean that we have to setup an Elasticsearch instance >>>>>> for each gateway? >>>>>> >>>>>> On the other point, if the gateways operate as logical unit, why is >>>>>> there a configuration option in the ui? >>>>>> >>>>>> >>>>>> >>>>>> Can you explain this a little bit more detailed? Maybe you have a >>>>>> configuration example. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Florian >>>>>> >>>>>> >>>>>> >>>>>> *Von:* Eric Wittmann >>>>>> *Gesendet:* Friday, 30 November 2018 14:22 >>>>>> *An:* Volk, Florian >>>>>> *Cc:* chttl582 at gmail.com; Marc Savy ; Kihm, >>>>>> Benjamin ; Gebert, Alfred < >>>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org >>>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific >>>>>> gateway >>>>>> >>>>>> >>>>>> >>>>>> Are both gateways using the same persistent storage? Each gateway >>>>>> would need separate, independent persistence otherwise they will behave as >>>>>> a single "logical" gateway. >>>>>> >>>>>> >>>>>> >>>>>> -Eric >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian < >>>>>> Florian.Volk at scheer-group.com> wrote: >>>>>> >>>>>> Hello together, >>>>>> >>>>>> >>>>>> >>>>>> I was interested in this and made a short test in my loacal >>>>>> environment and I am able to reproduce this. >>>>>> >>>>>> I created a ticket on github for this ( >>>>>> https://github.com/apiman/apiman/issues/711). We may can fix this >>>>>> shortly. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Florian >>>>>> >>>>>> >>>>>> >>>>>> *Von:* apiman-user-bounces at lists.jboss.org < >>>>>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang >>>>>> *Gesendet:* Friday, 30 November 2018 03:28 >>>>>> *An:* marc.savy at redhat.com >>>>>> *Cc:* apiman-user at lists.jboss.org >>>>>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway >>>>>> >>>>>> >>>>>> >>>>>> Dear Marc >>>>>> >>>>>> >>>>>> >>>>>> Yes I untick another gateway however request towards both gateways >>>>>> still works. >>>>>> >>>>>> Besides I tried to publish API via admin REST API (post api version >>>>>> then put gateway info), both gateways forwards request too. >>>>>> >>>>>> Before filing a bug is there any apigw setting I shall check? (such >>>>>> as parameter in apiman.properties or etc...) >>>>>> >>>>>> Thanks for your help. >>>>>> >>>>>> Regards >>>>>> >>>>>> Marc Savy ? 2018?11?21? ?? ??9:35??? >>>>>> >>>>>> Apologies for the terribly slow reply. We've had so much spam I've >>>>>> missed legitimate emails like this. >>>>>> >>>>>> >>>>>> >>>>>> Did you explicitly untick the other gateway? Was this via the UI or >>>>>> the API? >>>>>> >>>>>> >>>>>> >>>>>> Did you resolve this issue? If not, please file a bug: >>>>>> https://github.com/apiman/apiman/issues >>>>>> >>>>>> >>>>>> >>>>>> On Thu, 4 Oct 2018 at 05:00, Jon Huang wrote: >>>>>> >>>>>> Dears >>>>>> >>>>>> >>>>>> >>>>>> I had set up 2 gateways. >>>>>> >>>>>> When I new an API, I have to choose which gateway to publish. (select >>>>>> list at Gateway section in the implementation tab). >>>>>> >>>>>> However after creating a client app and contract for test, I found >>>>>> request via another gateway still works. >>>>>> >>>>>> (I guest when publishing to gateway 1 and request via gateway 2 shall >>>>>> fail) >>>>>> >>>>>> Am I misunderstanding or I miss some settings to make it work? >>>>>> >>>>>> Thanks >>>>>> >>>>>> _______________________________________________ >>>>>> 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/20181218/0c5384e6/attachment-0001.html From marc.savy at redhat.com Tue Dec 18 12:04:39 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 18 Dec 2018 17:04:39 +0000 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: Just to confirm: the purpose of the CORS plugin is to provide a CORS frontend to a service which does not currently have CORS. It is not to bypass CORS on a backend service that *already* has CORS. I believe you may be misunderstanding how the CORS protocol works. >From my recollection, if you are doing a non-simple request (such as yours), then you must execute a preflight request first (which is a special type of OPTIONS request -- https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests ). The browser first executes the preflight request, THEN it separately and subsequently executes the real request. So, if you were attempting to execute an OPTIONS request then you would execute 2 separate calls. This is done on your behalf transparently by the browser. The 'real' call is approved by virtue of the preflight request, and does not require the CORS headers you're including (which make it look like a preflight request). Please see: https://mdn.mozillademos.org/files/16401/preflight_.png If you are doing a *simple* request, as per the CORS specification, then no preflight is required and you embed the headers in the 'real' request as your samples show. Does this resolve your issue? On Tue, 18 Dec 2018 at 12:59, Renato Barros wrote: > Hello Marc, > > I don't think the problem is associated with *Access-Control-Allow-Origin*. > Below there are two requests using Restlet Client, the first one works > without the *Header Access-Controle-Request-Method*, the second only > adding this Header gets fail. > > > [image: image.png] > > On Tue, 18 Dec 2018 at 09:40, Marc Savy wrote: > >> I think your issue might be the way that you're formulating your request. >> >> In order to issue a valid CORS request, you must set your origin header. >> You should probably try that first. >> >> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin >> >> e.g. curl ... -H "Origin: mymachine.local" >> >> When using a browser, this is usually issued on your behalf. But, if >> you're using curl, it won't be. >> >> >> On Tue, 18 Dec 2018 at 12:35, Renato Barros >> wrote: >> >>> Hi Marc, >>> >>> I've just updated the image with details. The >>> Access-Control-Allow-Origin already had "*" as value. >>> >>> [image: image.png] >>> >>> On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: >>> >>>> I'm not sure why your browser isn't rendering it, but there should be a >>>> list in the Access-Control-Allow-Origin section that would allow you to add >>>> an entry such as "*" or "foo.com". >>>> >>>> What is your setup? >>>> >>>> On Mon, 17 Dec 2018 at 19:10, Renato Barros >>>> wrote: >>>> >>>>> Hello all, >>>>> >>>>> I'm getting an error with *Access-Control-Request-Method* Header in >>>>> my APIs. >>>>> >>>>> I posted details in StackOverflow >>>>> >>>>> . >>>>> >>>>> Please, someone could help me? >>>>> _______________________________________________ >>>>> 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/20181218/e2b17da6/attachment.html From renalexster at gmail.com Tue Dec 18 12:29:30 2018 From: renalexster at gmail.com (Renato Barros) Date: Tue, 18 Dec 2018 14:29:30 -0300 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: Thanks for your reply Marc, About the OPTIONS request: It results from the preflight request, so it's not the real request. My frontend is attempting to do a POST request. However, before this, a preflight is sent to the server automatically. The matter is *The Preflight Request Fails* [image: image.png] The POST request works. My question is: Is there some problem with my CORS Policy? Should I disable (turn False) Terminate on Cors Error? Or It's the result of some CORS plugin problem? On Tue, 18 Dec 2018 at 14:04, Marc Savy wrote: > Just to confirm: the purpose of the CORS plugin is to provide a CORS > frontend to a service which does not currently have CORS. It is not to > bypass CORS on a backend service that *already* has CORS. > > I believe you may be misunderstanding how the CORS protocol works. > > From my recollection, if you are doing a non-simple request (such as > yours), then you must execute a preflight request first (which is a special > type of OPTIONS request -- > https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests > ). > > The browser first executes the preflight request, THEN it separately and > subsequently executes the real request. So, if you were attempting to > execute an OPTIONS request then you would execute 2 separate calls. This is > done on your behalf transparently by the browser. > > The 'real' call is approved by virtue of the preflight request, and does > not require the CORS headers you're including (which make it look like a > preflight request). > > Please see: https://mdn.mozillademos.org/files/16401/preflight_.png > > If you are doing a *simple* request, as per the CORS specification, then > no preflight is required and you embed the headers in the 'real' request as > your samples show. > > Does this resolve your issue? > > On Tue, 18 Dec 2018 at 12:59, Renato Barros wrote: > >> Hello Marc, >> >> I don't think the problem is associated with >> *Access-Control-Allow-Origin*. Below there are two requests using >> Restlet Client, the first one works without the *Header >> Access-Controle-Request-Method*, the second only adding this Header gets >> fail. >> >> >> [image: image.png] >> >> On Tue, 18 Dec 2018 at 09:40, Marc Savy wrote: >> >>> I think your issue might be the way that you're formulating your request. >>> >>> In order to issue a valid CORS request, you must set your origin header. >>> You should probably try that first. >>> >>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin >>> >>> e.g. curl ... -H "Origin: mymachine.local" >>> >>> When using a browser, this is usually issued on your behalf. But, if >>> you're using curl, it won't be. >>> >>> >>> On Tue, 18 Dec 2018 at 12:35, Renato Barros >>> wrote: >>> >>>> Hi Marc, >>>> >>>> I've just updated the image with details. The >>>> Access-Control-Allow-Origin already had "*" as value. >>>> >>>> [image: image.png] >>>> >>>> On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: >>>> >>>>> I'm not sure why your browser isn't rendering it, but there should be >>>>> a list in the Access-Control-Allow-Origin section that would allow you to >>>>> add an entry such as "*" or "foo.com". >>>>> >>>>> What is your setup? >>>>> >>>>> On Mon, 17 Dec 2018 at 19:10, Renato Barros >>>>> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> I'm getting an error with *Access-Control-Request-Method* Header in >>>>>> my APIs. >>>>>> >>>>>> I posted details in StackOverflow >>>>>> >>>>>> . >>>>>> >>>>>> Please, someone could help me? >>>>>> _______________________________________________ >>>>>> 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/20181218/0625298e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 92809 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/0625298e/attachment-0001.png From renalexster at gmail.com Tue Dec 18 12:54:54 2018 From: renalexster at gmail.com (Renato Barros) Date: Tue, 18 Dec 2018 14:54:54 -0300 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: Sorry Marc, I misunderstood the concept of CORS and the plugin. My APIs are already prepared to use CORS requests. So that, I even don't need to create a CORS Policy in the APIMan. On Tue, 18 Dec 2018 at 14:29, Renato Barros wrote: > Thanks for your reply Marc, > > About the OPTIONS request: It results from the preflight request, so it's > not the real request. My frontend is attempting to do a POST request. > However, before this, a preflight is sent to the server automatically. The > matter is *The Preflight Request Fails* > > [image: image.png] > > The POST request works. > > My question is: Is there some problem with my CORS Policy? Should I > disable (turn False) Terminate on Cors Error? Or It's the result of some > CORS plugin problem? > > On Tue, 18 Dec 2018 at 14:04, Marc Savy wrote: > >> Just to confirm: the purpose of the CORS plugin is to provide a CORS >> frontend to a service which does not currently have CORS. It is not to >> bypass CORS on a backend service that *already* has CORS. >> >> I believe you may be misunderstanding how the CORS protocol works. >> >> From my recollection, if you are doing a non-simple request (such as >> yours), then you must execute a preflight request first (which is a special >> type of OPTIONS request -- >> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests >> ). >> >> The browser first executes the preflight request, THEN it separately and >> subsequently executes the real request. So, if you were attempting to >> execute an OPTIONS request then you would execute 2 separate calls. This is >> done on your behalf transparently by the browser. >> >> The 'real' call is approved by virtue of the preflight request, and does >> not require the CORS headers you're including (which make it look like a >> preflight request). >> >> Please see: https://mdn.mozillademos.org/files/16401/preflight_.png >> >> If you are doing a *simple* request, as per the CORS specification, then >> no preflight is required and you embed the headers in the 'real' request as >> your samples show. >> >> Does this resolve your issue? >> >> On Tue, 18 Dec 2018 at 12:59, Renato Barros >> wrote: >> >>> Hello Marc, >>> >>> I don't think the problem is associated with >>> *Access-Control-Allow-Origin*. Below there are two requests using >>> Restlet Client, the first one works without the *Header >>> Access-Controle-Request-Method*, the second only adding this Header >>> gets fail. >>> >>> >>> [image: image.png] >>> >>> On Tue, 18 Dec 2018 at 09:40, Marc Savy wrote: >>> >>>> I think your issue might be the way that you're formulating your >>>> request. >>>> >>>> In order to issue a valid CORS request, you must set your origin >>>> header. You should probably try that first. >>>> >>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin >>>> >>>> e.g. curl ... -H "Origin: mymachine.local" >>>> >>>> When using a browser, this is usually issued on your behalf. But, if >>>> you're using curl, it won't be. >>>> >>>> >>>> On Tue, 18 Dec 2018 at 12:35, Renato Barros >>>> wrote: >>>> >>>>> Hi Marc, >>>>> >>>>> I've just updated the image with details. The >>>>> Access-Control-Allow-Origin already had "*" as value. >>>>> >>>>> [image: image.png] >>>>> >>>>> On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: >>>>> >>>>>> I'm not sure why your browser isn't rendering it, but there should be >>>>>> a list in the Access-Control-Allow-Origin section that would allow you to >>>>>> add an entry such as "*" or "foo.com". >>>>>> >>>>>> What is your setup? >>>>>> >>>>>> On Mon, 17 Dec 2018 at 19:10, Renato Barros >>>>>> wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I'm getting an error with *Access-Control-Request-Method* Header in >>>>>>> my APIs. >>>>>>> >>>>>>> I posted details in StackOverflow >>>>>>> >>>>>>> . >>>>>>> >>>>>>> Please, someone could help me? >>>>>>> _______________________________________________ >>>>>>> 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/20181218/4d46cf8f/attachment.html From marc.savy at redhat.com Tue Dec 18 15:12:22 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 18 Dec 2018 20:12:22 +0000 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: No problem, glad we cleared it up! On Tue, 18 Dec 2018 at 17:55, Renato Barros wrote: > Sorry Marc, > > I misunderstood the concept of CORS and the plugin. My APIs are already > prepared to use CORS requests. So that, I even don't need to create a CORS > Policy in the APIMan. > > On Tue, 18 Dec 2018 at 14:29, Renato Barros wrote: > >> Thanks for your reply Marc, >> >> About the OPTIONS request: It results from the preflight request, so it's >> not the real request. My frontend is attempting to do a POST request. >> However, before this, a preflight is sent to the server automatically. The >> matter is *The Preflight Request Fails* >> >> [image: image.png] >> >> The POST request works. >> >> My question is: Is there some problem with my CORS Policy? Should I >> disable (turn False) Terminate on Cors Error? Or It's the result of some >> CORS plugin problem? >> >> On Tue, 18 Dec 2018 at 14:04, Marc Savy wrote: >> >>> Just to confirm: the purpose of the CORS plugin is to provide a CORS >>> frontend to a service which does not currently have CORS. It is not to >>> bypass CORS on a backend service that *already* has CORS. >>> >>> I believe you may be misunderstanding how the CORS protocol works. >>> >>> From my recollection, if you are doing a non-simple request (such as >>> yours), then you must execute a preflight request first (which is a special >>> type of OPTIONS request -- >>> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests >>> ). >>> >>> The browser first executes the preflight request, THEN it separately and >>> subsequently executes the real request. So, if you were attempting to >>> execute an OPTIONS request then you would execute 2 separate calls. This is >>> done on your behalf transparently by the browser. >>> >>> The 'real' call is approved by virtue of the preflight request, and does >>> not require the CORS headers you're including (which make it look like a >>> preflight request). >>> >>> Please see: https://mdn.mozillademos.org/files/16401/preflight_.png >>> >>> If you are doing a *simple* request, as per the CORS specification, then >>> no preflight is required and you embed the headers in the 'real' request as >>> your samples show. >>> >>> Does this resolve your issue? >>> >>> On Tue, 18 Dec 2018 at 12:59, Renato Barros >>> wrote: >>> >>>> Hello Marc, >>>> >>>> I don't think the problem is associated with >>>> *Access-Control-Allow-Origin*. Below there are two requests using >>>> Restlet Client, the first one works without the *Header >>>> Access-Controle-Request-Method*, the second only adding this Header >>>> gets fail. >>>> >>>> >>>> [image: image.png] >>>> >>>> On Tue, 18 Dec 2018 at 09:40, Marc Savy wrote: >>>> >>>>> I think your issue might be the way that you're formulating your >>>>> request. >>>>> >>>>> In order to issue a valid CORS request, you must set your origin >>>>> header. You should probably try that first. >>>>> >>>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin >>>>> >>>>> e.g. curl ... -H "Origin: mymachine.local" >>>>> >>>>> When using a browser, this is usually issued on your behalf. But, if >>>>> you're using curl, it won't be. >>>>> >>>>> >>>>> On Tue, 18 Dec 2018 at 12:35, Renato Barros >>>>> wrote: >>>>> >>>>>> Hi Marc, >>>>>> >>>>>> I've just updated the image with details. The >>>>>> Access-Control-Allow-Origin already had "*" as value. >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> On Tue, 18 Dec 2018 at 05:50, Marc Savy wrote: >>>>>> >>>>>>> I'm not sure why your browser isn't rendering it, but there should >>>>>>> be a list in the Access-Control-Allow-Origin section that would allow you >>>>>>> to add an entry such as "*" or "foo.com". >>>>>>> >>>>>>> What is your setup? >>>>>>> >>>>>>> On Mon, 17 Dec 2018 at 19:10, Renato Barros >>>>>>> wrote: >>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> I'm getting an error with *Access-Control-Request-Method* Header >>>>>>>> in my APIs. >>>>>>>> >>>>>>>> I posted details in StackOverflow >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> Please, someone could help me? >>>>>>>> _______________________________________________ >>>>>>>> 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/20181218/0ebbd57a/attachment-0001.html From ashish.patel at futuregroup.in Wed Dec 19 07:05:13 2018 From: ashish.patel at futuregroup.in (Ashish Patel) Date: Wed, 19 Dec 2018 12:05:13 +0000 Subject: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method In-Reply-To: References: Message-ID: My two cent on below? Sorry if it spams your inbox. The CORS Policy Preflight request, as per specification has to be a GET request and so if we use APIMan CORS Policy, we have to send the ?apiKey? in get Request. We faced this issue and so sharing our experience (Preflight request was not sending apiKey as we configured in Header). Agree, sending ?apiKey? through GET is not recommended, but this is CORS preflight spec restriction and we have to leave with it. Any thoughts on how APIMan can help avoid that ? (allow preflight without apiKey on CORS request ?). From: apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Marc Savy Sent: Wednesday, December 19, 2018 01:42 To: Renato Barros Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] APIMan return error 400 for header Access-Control-Request-Method No problem, glad we cleared it up! On Tue, 18 Dec 2018 at 17:55, Renato Barros > wrote: Sorry Marc, I misunderstood the concept of CORS and the plugin. My APIs are already prepared to use CORS requests. So that, I even don't need to create a CORS Policy in the APIMan. On Tue, 18 Dec 2018 at 14:29, Renato Barros > wrote: Thanks for your reply Marc, About the OPTIONS request: It results from the preflight request, so it's not the real request. My frontend is attempting to do a POST request. However, before this, a preflight is sent to the server automatically. The matter is The Preflight Request Fails The POST request works. My question is: Is there some problem with my CORS Policy? Should I disable (turn False) Terminate on Cors Error? Or It's the result of some CORS plugin problem? On Tue, 18 Dec 2018 at 14:04, Marc Savy > wrote: Just to confirm: the purpose of the CORS plugin is to provide a CORS frontend to a service which does not currently have CORS. It is not to bypass CORS on a backend service that *already* has CORS. I believe you may be misunderstanding how the CORS protocol works. From my recollection, if you are doing a non-simple request (such as yours), then you must execute a preflight request first (which is a special type of OPTIONS request -- https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests). The browser first executes the preflight request, THEN it separately and subsequently executes the real request. So, if you were attempting to execute an OPTIONS request then you would execute 2 separate calls. This is done on your behalf transparently by the browser. The 'real' call is approved by virtue of the preflight request, and does not require the CORS headers you're including (which make it look like a preflight request). Please see: https://mdn.mozillademos.org/files/16401/preflight_.png If you are doing a *simple* request, as per the CORS specification, then no preflight is required and you embed the headers in the 'real' request as your samples show. Does this resolve your issue? On Tue, 18 Dec 2018 at 12:59, Renato Barros > wrote: Hello Marc, I don't think the problem is associated with Access-Control-Allow-Origin. Below there are two requests using Restlet Client, the first one works without the Header Access-Controle-Request-Method, the second only adding this Header gets fail. On Tue, 18 Dec 2018 at 09:40, Marc Savy > wrote: I think your issue might be the way that you're formulating your request. In order to issue a valid CORS request, you must set your origin header. You should probably try that first. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin e.g. curl ... -H "Origin: mymachine.local" When using a browser, this is usually issued on your behalf. But, if you're using curl, it won't be. On Tue, 18 Dec 2018 at 12:35, Renato Barros > wrote: Hi Marc, I've just updated the image with details. The Access-Control-Allow-Origin already had "*" as value. On Tue, 18 Dec 2018 at 05:50, Marc Savy > wrote: I'm not sure why your browser isn't rendering it, but there should be a list in the Access-Control-Allow-Origin section that would allow you to add an entry such as "*" or "foo.com". What is your setup? On Mon, 17 Dec 2018 at 19:10, Renato Barros > wrote: Hello all, I'm getting an error with Access-Control-Request-Method Header in my APIs. I posted details in StackOverflow. Please, someone could help me? _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user Accept the Challenge. Go Paperless -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181219/b21f119d/attachment-0001.html From stephen at chassi.com Thu Dec 27 22:24:01 2018 From: stephen at chassi.com (Stephen Henrie) Date: Thu, 27 Dec 2018 20:24:01 -0700 Subject: [Apiman-user] Elasticsearch parse exception when displaying metrics Message-ID: I have a production installation of Apiman 1.3.1 running with the 1.7 version of elastic search that has been up for a few months in an openshift. Only recently, the API metrics are no longer displaying and I am getting the error below in the elasticsearch log. The API requests still seem to be processed by Apiman, but clearly the metrics are not being collected, or if they are, the query is failing when trying to display them. I realize that this is not an elastic search support forum, but I was hoping tat someone would know what is involved to fix the metrics for Apiman. I have tried restarting the elasticsearch service, but that has not fixed the issue. Could this error have happen if the volume was corrupted? If I were to clear the storage volume and restart the elastic search node, what would have to happen on Apiman? Would all of the APIs have to be republished? Is this a common thing that happens with Apiman and elastic search? Thanks in advance Stephen Henrie *[2018-12-28 02:59:54,387][DEBUG][action.search.type ] [Corruptor] [apiman_metrics][3], node[r24FvIHkQN69_8nmw31Yqg], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest at 3049c571] lastShard [true] * *org.elasticsearch.search.SearchParseException: [apiman_metrics][3]: from[-1],size[-1]: Parse Failure [Failed to parse source [{ "query": { "bool": { "filter": [{ "term": { "apiOrgId": "chassi" } }, { "term": { "apiId": "tenant" } }, { "term": { "apiVersion": "1" } }, { "range": { "requestStart": { "gte": "2018-12-20T07:00:00Z", "lte": "2018-12-28T02:59:54Z" } } } ] } }, "size": 0, "aggs": { "usage_by_plan": { "terms": { "field": "planId" } } }}]] * * at org.elasticsearch.search.SearchService.parseSource(SearchService.java:747) * * at org.elasticsearch.search.SearchService.createContext(SearchService.java:572) * * at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:544) * * at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:306) * * at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:231) * * at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:228) * * at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:559) * * at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) * * at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) * * at java.lang.Thread.run(Thread.java:745) * *Caused by: org.elasticsearch.index.query.QueryParsingException: [apiman_metrics] bool query does not support [filter] * * at org.elasticsearch.index.query.BoolQueryParser.parse(BoolQueryParser.java:113) * * at org.elasticsearch.index.query.QueryParseContext.parseInnerQuery(QueryParseContext.java:307) * * at org.elasticsearch.index.query.IndexQueryParserService.innerParse(IndexQueryParserService.java:382) * * at org.elasticsearch.index.query.IndexQueryParserService.parse(IndexQueryParserService.java:281) * * at org.elasticsearch.index.query.IndexQueryParserService.parse(IndexQueryParserService.java:276) * * at org.elasticsearch.search.query.QueryParseElement.parse(QueryParseElement.java:33) * * at org.elasticsearch.search.SearchService.parseSource(SearchService.java:731) * * ... 9 more* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181227/64cce9f3/attachment.html From navaleshubham2410 at gmail.com Fri Dec 7 03:33:54 2018 From: navaleshubham2410 at gmail.com (Shubham Navale) Date: Fri, 07 Dec 2018 08:33:54 -0000 Subject: [Apiman-user] [APIMAN] Failed to retire apis after docker restart Message-ID: So, I am using apiman 1.5.1 which is using MYSQL 8 as a database, along with external keycloak with client status public. The whole thing is running in docker. So, I have configured the gateway in apiman. And registered some apis. Now when I restart my docker of apiman, the gateway resets itself to its old setting. So, I reconfigured the gateway with my settings. But now when I am trying to retire my registered apis, it's throwing me some error. Error:- https://gist.github.com/ElavanResu/985ff4349ae81888581d320eb17e1f88 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181207/bca71c5d/attachment-0001.html