Question: How to stop path segments & query parameters from going on to the back-end API endpoint?
by Manvendra.Rai＠ril.com
Hello All,
I left this question on freenode - IRC and though to post the same on the email group.
Question: We are using API Gateway for couple of things and one of the main functionalities we are leveraging is - Managed API.
Our requirement is to create a Plugin which will invoke backend API after fetching fielded from the database based on the object id from the Manage URL.
Say for example -
My manage API is -
http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid}<http://abc.com/apiman-gateway/testapp/manav/3.0/images/%7bobjectid%7d>
My Backend API
http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fileid}<http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/%7bfileid%7d>
We have implemented almost all this requirement but have one issue. As per the default behaviour, API Gateway proxies all path segments beyond the {version} segment with query parameters back-end API.
This is causing an issue because [objected] is also being sent to Backend API.
So my question is to know - how can we stop {objected} from going to Backend API?
Thanks for your time looking at the issue and advising back.
Thanks,
Manav
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s).
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email.
and delete this message and any attachments from your system.
Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email.
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
9 years, 7 months
APIMAN Analytics
by Mohan
Hi APIMAN Team,
While going through APIMAN’s Analytics functionality, I have found out that
you need to open individual APIs to see following stats
1 ) Usage of a given API per client and per plan
2) # of Successful/Failed/erroneous responses
I would like to know is there any way for us to get following reports in
APIMAN
1. Is there any way to see above statistics for *ALL published API*s
at *ONE* place without having to go through each APIs?
2. And, For a given time period
a. Among all the published APIs, show me the APIs for which we had
issues/(# faulty API calls per API) so that I know the problematic APIs and
can take corrective action.
b. Among the published APIs, show me the number of subscriptions
(Example : API-1 has 1 subscriber/ClientApp, API-2 has 3
subscriber/clientApp) to measure the adoption rate for a given API
c. Among the published APIs, show me the number of APIs call made per
API and their response time (so that I know which APIs are slow and I can
take corrective action to improve the performance)
d. Number of API calls per user/clientApp (This will help developer to
see whether to reduce their usage of API calls or not and also helps the
service provider to know which developer are exceeding their quota).
Appreciate your feedback/response
Best
Mohan Joyappa (@ ebsco)
9 years, 7 months
Re: [Apiman-user] APIMAN rate limiting policy granularity
by Eric Wittmann
(adding the apiman-user list for posterity)
Thanks for the question. Here are definitions of these two granularities:
User: only possible when also using Authentication (basic or oauth),
the granularity is based off the username of the authenticated user as
well as the API information. In other words, the "rate limiting counter
id" for this would be:
username+apiOrgId+apiId+apiVersion
Client: only possible for non-public APIs - this is based off the API
Key of the client app issuing the rquest. In other words, the "rate
limiting counter id" for this would be:
API Key+apiOrgId+apiId+apiVersion
I hope that helps!
-Eric
On 5/26/2016 3:40 PM, Subbarao Denduluri wrote:
> The granularity shows: user , api and client. What is the difference between user and client. And also thinking of putting the policy at the APIKEY level. Does that mean the user level?
>
> thanks
>
9 years, 7 months
Re: [Apiman-user] Question about Test Gateway endpoint
by Eric Wittmann
The available time granularity is really the only difference. Typically
a Quota is something like "10,000 requests per month" while a Rate Limit
is more like "100 requests per minute".
Often times you may want BOTH of these added for the same API.
-Eric
On 5/26/2016 3:18 PM, Subbarao Denduluri wrote:
> Eric,
>
> Is there any difference between rate limiting policy and Quota policy. Both seem to show number of requests per second
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann@redhat.com]
> Sent: Thursday, May 26, 2016 1:37 PM
> To: Subbarao Denduluri <sdenduluri(a)ebsco.com>
> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>
> The IP whitelist policy is built-in to core - it doesn't require a plugin.
>
> -Eric
>
> On 5/26/2016 12:43 PM, Subbarao Denduluri wrote:
>> Thanks Eric for the response. Good to know. One more thing I would like to ask. I want to use the IP whitelisting policy. We are using the 1.2.5 version of apiman. Do I have to add any plugin to accomplish the whitelisting or is it inbuilt?
>>
>> Thanks
>> Subba
>>
>> -----Original Message-----
>> From: Eric Wittmann [mailto:eric.wittmann@redhat.com]
>> Sent: Wednesday, May 18, 2016 9:05 AM
>> To: Subbarao Denduluri <sdenduluri(a)ebsco.com>;
>> apiman-user(a)lists.jboss.org
>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>
>> I don't have a specific timeline for this, but Swagger would
>> definitely be the first to be implemented. There is more of a
>> preference for Swagger within Red Hat and also in the apiman community
>> (from what I can
>> tell) vs. RAML.
>>
>> -Eric
>>
>> On 5/17/2016 1:39 PM, Subbarao Denduluri wrote:
>>> Thanks for your reply Eric. Actually is there priotity in your
>>> timelines to support Swagger or Raml. Like which particular
>>> technology would be available first to import if at all you are
>>> planning to support either of these
>>>
>>> Thanks
>>> Subba
>>>
>>> -----Original Message-----
>>> From: Eric Wittmann [mailto:eric.wittmann@redhat.com]
>>> Sent: Tuesday, May 17, 2016 8:34 AM
>>> To: Subbarao Denduluri <sdenduluri(a)ebsco.com>
>>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>>
>>> Unfortunately we don't yet have support for importing APIs into the manager from swagger. It's something that we *want* but haven't implemented yet. There is an "Import APIs" UI already, which is designed to support things like:
>>>
>>> * swagger
>>> * raml
>>> * wadl
>>> * wsdl
>>>
>>> However, currently it only supports the internal "API Catalog" concept that apiman has.
>>>
>>> -Eric
>>>
>>>
>>> On 5/16/2016 4:29 PM, Subbarao Denduluri wrote:
>>>> Hello Eric,
>>>>
>>>> I have a question on Apiman swagger integration. I am looking into apiman support for an api import from a swagger file. Does Apiman have support like that?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: apiman-user-bounces(a)lists.jboss.org
>>>> [mailto:apiman-user-bounces@lists.jboss.org] On Behalf Of Eric
>>>> Wittmann
>>>> Sent: Monday, May 16, 2016 9:43 AM
>>>> To: Helio Frota <00hf11(a)gmail.com>; apiman-user
>>>> <apiman-user(a)lists.jboss.org>
>>>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>>>
>>>> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to test whether a particular Gateway configuration would likely work if it were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].
>>>>
>>>> This is used by the UI on both the New Gateway and Edit Gateway pages.
>>>> See the attached screenshot for details. When the user clicks the "Test Gateway" button, the UI sends the gateway configuration details from the form to validate whether the settings are likely correct. The API Manager (/apiman) will try to make a connection to the API Gateway to see if it can be reached and whether authentication succeeds. If all goes well, the user can be reasonably certain that she has inputted correct information in the form.
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On 5/12/2016 12:47 PM, Helio Frota wrote:
>>>>> Hi all,
>>>>>
>>>>> From REST docs:
>>>>>
>>>>> 'This endpoint is used to test the Gateway's settings prior to
>>>>> either creating or updating it. The information will be used to
>>>>> attempt to create a link between the API Manager and the Gateway,
>>>>> by simply trying to ping the Gateway's "status" endpoint.'
>>>>>
>>>>> This part:
>>>>> 'The information will be used to attempt to create a link between
>>>>> the API Manager and the Gateway'
>>>>>
>>>>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>>>>
>>>>>
>>>>> This means the endpoint 'http://localhost:8080/apiman/gateways/'
>>>>> [PUT] is used for/to/only Apiman itself ? This can be used by other
>>>>> clients or it no makes much sense ?
>>>>>
>>>>> Thanks !
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
9 years, 7 months
PluginNotFoundException when adding a new plugin
by Helio Frota
Hi ,
I'm trying to use the endpoint :
http://localhost:8080/apiman/plugins/ [ POST ]
' Use this endpoint to add a plugin to apiman. '
Using this object representation:
let plug = {
name: 'the-new-plugin',
description: 'the description',
type: 'plugs',
version: '1.0.0.Final',
groupId: 'org.myplugins',
artifactId: 'superplugin',
classifier: '1',
upgrade: false
};
And I'm getting this error :
type: 'PluginNotFoundException',
errorCode: 12002,
message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
moreInfoUrl: null,
stacktrace:
'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
...
Maybe I'm populating the object with wrong values ? [ e.g classifier ? ]
Thanks
9 years, 7 months
APIMAN MTLS struggles: ssuggestions
by Amit Joshi
Hello,
I have been following the information in the blog post: http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/201... but has a tough time. I had a simple Java test program that worked against the Api with setting the has a trust store etc. using system properties:
System.setProperty("javax.net.ssl.trustStore", System.getProperty("truststore.path"));
System.setProperty("javax.net.ssl.trustStorePassword", System.getProperty("keystore.password"));
System.setProperty("javax.net.ssl.keyStore", System.getProperty("keystore.path"));
System.setProperty("javax.net.ssl.keyStorePassword", System.getProperty("keystore.password"));
System.setProperty("javax.net.ssl.keyStoreType", System.getProperty("keystore.type"));
However, when I try to do the same , but using APIMan (and setting the properties in the apiman.properties file) to gateway the API it fails as below. I tried setting the -Djavax.net.debug.all (as suggested in the article) which gives a lot more in the logs but all I could see that looked relevant: "Warning: no suitable certificate found - continuing without client authentication" which made no sense since I have the correct cert and it works with the test program.
I finally figured out the issue - the MTLS setup does not allow you to pass in the keyStoreType and my keystore was PKCS12 and not JKS.
Couple of suggestions as a result:
* Add the ability to set the keyStoreType so we won't have to convert them
* Also the stacktrace gets truncated in the output (see below) and its very difficult to diagnose what the problem is - something I think would have been minutes if I could have seen the message about not being able to load the keystore took hours.
* Also I want to be able to automatically use different keystores based on the api or logged-in user or url etc. My thought was to extend the HttpConnectorFactory and override the TlsOptions. However the class has all the properties private with no getters/setters and so it is difficult to do so that. This means I have to pretty much make a copy of the class instead of just a custom extension . Would be good if the class had public or at least protected getters/setters there so I could override the keystore based on some rules..
Results when running against apiman but with a pkcs12 keystore:
Using the Advanced Rest Client app for Chrome. I see the following as a response
X-Gateway-Error: Not connected.
500 Internal Server Error
And the response looks as follows. Note that the message is generic "Not connected" and the stack trace is missing any information about why the connection failed.
{
"responseCode": 500,
"message": "Not connected.",
"trace": "io.apiman.gateway.engine.beans.exceptions.ConnectorException: Not connected.\n\tat io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:332)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$1(ApiRequestExecutorImpl.java:234)\n\tat io.apiman.gateway.engine.io.AbstractStream.handleBody(AbstractStream.java:107)\n\tat io.apiman.gateway.engine.policy.Chain.write(Chain.java:181)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$1.write(ApiRequestExecutorImpl.java:525)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:169)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:161)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:517)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:243)\n\tat io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\n\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:246)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:419)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$5(ApiRequestExecutorImpl.java:269)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:123)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:112)\n\tat io.apiman.gateway.engine.es.CachingESRegistry.getApi(CachingESRegistry.java:115)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper.getApi(SecureRegistryWrapper.java:112)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:252)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)\n\tat io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat java.lang.Thread.run(Thread.java:745)\nCaused by: java.io.IOException: Not connected.\n\tat io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:319)\n\t... 48 more\n"
}
Regards,
Amit Joshi
________________________________
This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page
Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
9 years, 7 months
Re: [Apiman-user] Question about Test Gateway endpoint
by Eric Wittmann
I don't have a specific timeline for this, but Swagger would definitely
be the first to be implemented. There is more of a preference for
Swagger within Red Hat and also in the apiman community (from what I can
tell) vs. RAML.
-Eric
On 5/17/2016 1:39 PM, Subbarao Denduluri wrote:
> Thanks for your reply Eric. Actually is there priotity in your timelines to support Swagger or Raml. Like which particular technology would be available first to import if at all you are planning to support either of these
>
> Thanks
> Subba
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann@redhat.com]
> Sent: Tuesday, May 17, 2016 8:34 AM
> To: Subbarao Denduluri <sdenduluri(a)ebsco.com>
> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>
> Unfortunately we don't yet have support for importing APIs into the manager from swagger. It's something that we *want* but haven't implemented yet. There is an "Import APIs" UI already, which is designed to support things like:
>
> * swagger
> * raml
> * wadl
> * wsdl
>
> However, currently it only supports the internal "API Catalog" concept that apiman has.
>
> -Eric
>
>
> On 5/16/2016 4:29 PM, Subbarao Denduluri wrote:
>> Hello Eric,
>>
>> I have a question on Apiman swagger integration. I am looking into apiman support for an api import from a swagger file. Does Apiman have support like that?
>>
>> Thanks!
>>
>>
>> -----Original Message-----
>> From: apiman-user-bounces(a)lists.jboss.org
>> [mailto:apiman-user-bounces@lists.jboss.org] On Behalf Of Eric
>> Wittmann
>> Sent: Monday, May 16, 2016 9:43 AM
>> To: Helio Frota <00hf11(a)gmail.com>; apiman-user
>> <apiman-user(a)lists.jboss.org>
>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>
>> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to test whether a particular Gateway configuration would likely work if it were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].
>>
>> This is used by the UI on both the New Gateway and Edit Gateway pages.
>> See the attached screenshot for details. When the user clicks the "Test Gateway" button, the UI sends the gateway configuration details from the form to validate whether the settings are likely correct. The API Manager (/apiman) will try to make a connection to the API Gateway to see if it can be reached and whether authentication succeeds. If all goes well, the user can be reasonably certain that she has inputted correct information in the form.
>>
>> -Eric
>>
>>
>> On 5/12/2016 12:47 PM, Helio Frota wrote:
>>> Hi all,
>>>
>>> From REST docs:
>>>
>>> 'This endpoint is used to test the Gateway's settings prior to either
>>> creating or updating it. The information will be used to attempt to
>>> create a link between the API Manager and the Gateway, by simply
>>> trying to ping the Gateway's "status" endpoint.'
>>>
>>> This part:
>>> 'The information will be used to attempt to create a link between the
>>> API Manager and the Gateway'
>>>
>>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>>
>>>
>>> This means the endpoint 'http://localhost:8080/apiman/gateways/'
>>> [PUT] is used for/to/only Apiman itself ? This can be used by other
>>> clients or it no makes much sense ?
>>>
>>> Thanks !
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
9 years, 7 months
