We got strange behavior on API Manager.
We updated our API's swagger file inside WSO2 Publisher. And we deployed it to our dev environment. It has only 2 resources. Everything was working, we can send requests to our gateway endpoint url and we can get responses as expected.
Then, we just wanted to add only a "s" letter to one resource's path. We updated the swagger in WSO2, also we deployed our API in our dev env again. Now, this resource doesn't work with new path name. It responses as shown in the picture. Other resource is working. But this not. Strangely, it works by using our service endpoint url directly. We found a solution by creating a new 1.0.1 version of same API. Now all resources are working. If we downgrade the version to 1.0.0, again this resource doesn't work.
I'm exactly sure there is no line shifting, missing character, missing tabs or etc. I see the resources on preview on API definition page.
What is the problem? Is this a bug? I think the 1.0.0 is storing on somewhere like cache or etc.
Related
I am trying to make /oauth2/token API call from reactjs fronted and getting CORS error.
My friend asked the same question and got answer for the same also.
Please open the link for solution.
WSO2 IS returns CORS error when wrong credentials sent
But when I am trying to perform the same in WSO2IS 5.9.0 the configuration is getting overwritten to the default config.
How to perform this in 5.9.0 using deployment.toml file?
As I have mentioned in that earlier answer you need to add the given tomcat filter in the web.xml.j2 file in the path repository/resources/conf/templates/repository/conf/tomcat. The .j2 files will not get replaced by the deployment.toml at the server startup.
I am doing a POC with my team as we are introducing WSO2 components and am working with the API Manager 3.0.
I seem to be having issues loading the WSO2 API Manager / API Publisher on the defined URL;
https://[ip address]/publisher
The page is not loading and I keep getting a spinning circle.
Steps I have taken:
Stop API Manager at command prompt with [Ctrl + C] command
Modified deployment.toml file specified paths for the localhost to our IP Address, API [publisher, gateway and store] URL values to use our IP Address as well.
Changed carbon.xml and api_manager.xml
Start API Manager with wso2server.bat --run command
Issues are as follows;
api_manager.xml values are reset to localhost and not the IP Address I modified it to.
The API Publisher page is not loading and I am not able to get to the API Publisher login page.
I am an administrator on the Windows Server hosting this, so all changes are made as admin.
First of all, APIM 3.0 has a new config model, where all configurations are available (only) in deployment.toml. All other configurations are populated based on that, and shouldn't be changed manually.
Second, you don't need to replace all occurrences of localhost to IP as many are local calls.
Third, the correct URL should have the port, unless you have a reverse proxy in front of API.
eg. https://[ip address]:9443/publisher
Sounds good and thanks for the input. I will give this a try and post back to the thread.
I am using the IP and Port for now with no reverse proxy but plan to add one, once I can get through this part.
Much appreciated.
I'm embedding Jetty 9.1 from within a Java application. I'm configuring everything programmatically; I am not using web.xml or Spring or anything else. I have Wicket mapped to /* and a RestEASY JAX-RS API mapped to /rest/*. That's all working fine.
I wanted to add HTTP authentication, so I added the following (based upon as much Jetty documentation as I find):
HashLoginService loginService = new HashLoginService();
loginService.setName("My Realm");
loginService.setConfig("src/main/resources/realm.properties");
server.addBean(loginService);
I added a user with a role of admin to realm.properties. Then I tried to configure my REST service, putting the following annotation on my main JAX-RS resource:
#RolesAllowed({ "admin" })
Then I added the following annotation to my main Wicket page:
#AuthorizeInstantiation("admin")
None of these changes made any difference; I can still use my browser to navigate to my REST API and Wicket pages.
I'm guessing I need to turn on DIGEST authentication in Jetty. But how do I do that programmatically, without a web.xml file? What else do I need to do?
Another answer to a similar question, providing a link to a sample webapp, helped me immensely and got me up and running.
In Jetty v7, you chain the handlers together:
server.setHandler(securityHandler);
securityHandler.setHandler(resourceHandler);
Works on my machine! (tm)
Is it possible to register endpoints with URI templates in the API Publisher that ships with WSO2 API Manager version 1.4.0? For example, I would like to register an endpoint such as:
/jobs/{jobid}/pems
After saving an API, I can see this bit in the API config file:
<resource methods="GET" url-mapping="/jobs/{jobid}/pems">
I have tried manually changing the XML file from url-mapping to uri-template, i.e., to:
<resource methods="GET" uri-template="/jobs/{jobid}/pems">
but I still get "No matching resource found in the API for the given request". In any case, this is not a good work around since we need developers to be able to register these endpoints from the publisher application. Whenever changes are saved to an API from within the API Publisher interface, 'uri-template' gets reverted back to 'url-mapping'.
Thanks in advance.
This is due to APIPublisher app only supports URL-Mappings when defining API resources.
If you want to define a uri-template ,instead of a url-mapping,you can achieve this from changing the api xml manually.
But before that make sure,when creating the API,you have define the API with a valid url-mapping.So in your trying API,first please edit the API from APIPublisher as keeping a valid url-mapping pattern for API resources and then change its xml to match with your mentioned uri-template pattern.
Thanks;
we don't currently support uri-template patterns. We support only url-mappings.
Even , if you edit the backend API configuration (that is, api configuration file ) to url-mappings, it wont work, because we validate request before the request get hits the mediation engine.
You can use ESB RESTApi as your backend service endpoint.That is, define the RESTAPI in wso2esb, with uri-templates(it is supported out of the in ESB) and point that API as the service endpoint from wso2APIManager with url-mappings pattern.
I would like to add some more points.As I mentioned earlier,WSO2 APIManager supports uri-templates.Only api-publisher app UI is not allowing to add uri-templates.
When creating the API from the Publisher UI, you have to give the resource mapping as /* or valid url-mapping. Then when the synapse api is created, you have to change that xml file to uri-template and then change the /* to the uri-template pattern.
Hope above will help you to resolve your issue.
Thanks;
I am configuring our API Manager, but running into troubles authenticating via OAuth, seems to be an issue with the API Key Manager. I haven't dug into it yet, but does this come with the API Manager (as I have assumed) or is this a separate installation?
I had the same issue when using the wso2 api manager on a Amazon hosted machine, turn out that Thrift was not working correctly because some problem with multicasting and broadcasting.
What I did to get it working was to switch from ThriftClient to WSClient. If you have a huge amount of requests coming in then Thrift is the recommended solution from wso2 but in any "normal" case you will not have any differences between thrift and WS.
Here is how you switch:
Shut down the API Manager
Open up <api manager install dir>\repository\conf\api-manager.xml
Find ThriftClient
Change this to
<KeyValidatorClientType>WSClient</KeyValidatorClientType>
Start the API Manager
You may get some Warnings while starting up but, try it before you jump to the conclusion that it doesn't work.
Hope it helps!
you can use APIM manager product in a distributed setup as keymanger,gateway,store,publisher..but all functionality come in a single distribution.. ..
Go through the documentation for further guides
I was facing the same issue. Everything started when I created my own jks in order to use SSL without a self-signed certificate. I successfully created the jks and changed it in the carbon file. When I started the server, everything seemed ok; but when I used SOAPUI to test an API call, I got this (in the logs of the api manager):
APIAuthenticationHandler API authentication failure due to Unclassified Authentication Failure
I started digging what was the problem by enabling Debug level in the log4j.properties file, and then tried again a tested with SOAPUI and I got:
APISecurityException: Could not connect to <my api ip address> on port 10397
Then, I read the comment of OneMuppet and I checked that file and I found that the Thrift config has a host option, so I uncommented it:
<KeyValidatorClientType>ThriftClient</KeyValidatorClientType>
<ThriftClientPort>10397</ThriftClientPort>
<ThriftClientConnectionTimeOut>10000</ThriftClientConnectionTimeOut>
<ThriftServerPort>10397</ThriftServerPort>
This Line --> <ThriftServerHost>localhost</ThriftServerHost>
<EnableThriftServer>true</EnableThriftServer>
Save, restarted the server and everything start working correctly.
I got the same below issue after my installation, when i try to invoke the api service it is throwing below error:
900900 Unclassified Authentication Failure Error while accessing backend services for API key validation
After some random checks i have seen the axis2.xml file in /repository/conf/axis2 there it is refering a differnt ip's instead. I change these ip's to my local ip and restarted. The issue is resolved now.
I was facing the same issue. when I was trying to setup API Manager as an API Gateway in a different machine as per the steps given here,
https://docs.wso2.com/display/AM250/Publish+through+Multiple+API+Gateways
Once the setup is done and when I am trying to use this gateway URL, I was getting the below response,
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
After changing the KeyValidatorClientType value to WSClient from ThriftClient on the <api manager install dir>\repository\conf\api-manager.xml
It started working fine. And I was able to get the expected response.
If you changed the admin password, then you also have to update the repository/conf/api-manager.xml file with the new password. The 2 places I have changed (so far) are:
<AuthManager>
and
<APIKeyManager>
but there are other admin usernames in that file. No doubt, I'll get to them....