I came across an issue using WSO2 Stratos 1.6.0 when trying to browse the registry. The browser just hangs when clicking on Resources > Browse. Having a look at the network traffic I see an HTTP POST request to /carbon/admin/jsp/session-validate.jsp that doesn't complete.
I then started debugging the org.apache.synapse.transport.passthru.ServerWorker (2.1.1-wsov1) in the WSO2ELB (2.0.2). I found that the code that writes the ACK to the response output stream is being skipped. This only appears to happen when POSTing to /carbon/admin/jsp/session-validate.jsp, when I hacked the /carbon/admin/js/main.js to perform a GET, everything worked fine.
So my question(s) being... is this a bug in main.js? is it a bug in ServerWorker in WSO2ELB? is there a special reason that the sessionAwareFunction in main.js uses POST as opposed to GET?
This is a bug in the transport ELB uses. Please use the latest release ELB http://wso2.com/products/elastic-load-balancer/
Related
I am trying to connect to an external API from .net.
It is working as expected from other machines.
But we are not getting any respond from the API call when trying from the server.
We have tried accessing the api url on the browser and it failed with the same no response error.
This is what we have done so far.
We have checked VPC firewall and tried some firewall rules ( Google Cloud firewall) and made sure that there is no blocking to this API.
We have checked Windows firewall and it is switched off now. We also made sure that there is no rules to block this API. However to test it further, we are now switched it off.
Checked that we are able to connect to other websites from the server.
Checked whether we can access the API from other machines. We are able to connect to the API successfully using the tokens from the server.
We have also installed Wireshark to analyze the incoming and outgoing packets from the server. From this analysis, we were able to find that there are network packets sending to this API and it is trying the retransmits the packets, but there is no acknowledgement packet received. This might be of the below two scenarios.
The acknowledgement packet sent from the API server lost in transition.
The data that we have sent from the server to the API lost in transition.
Contacted the API technical team and made sure that the IP is not getting blocked on their end.
Tried contacting Google Support but we have not received much help from them as ours are in "Bronze plan"
This was working without any issues from the server in the past. Not sure what is happening now.
Thank you in advance for all the helps.
Thank you Jeffrey and Patrick for your kind reply. As suggested by Patrick, I am adding here my comments as an answer to close this post. We were able to identify the issue from the wireshark analysis. It was the API provider who was blocking the IP. We have contacted them again with the results and they confirmed this. Thank you very much.
I'm using a Microsoft add-in for Powerpoint called 'Web Viewer' (it's just an iframe, you insert a URL, it displays it in the slide).
I inserted a webpage that uses Socket.IO, and I'm seeing it is not able to connect to the server (even the long polling it's falling back on is not working).
Clearly this is not an issue with the add-in: Any ideas what is going on here?
I tested on Mac 10.13.4 (latest) / Powerpoint (16.12, Office 365 Home) (latest).
The same webpage works in an iframe in the latest Chrome, Firefox, Safari, IE11, so I'm thinking something wonky is going on with the embedded (Webkit) browser that Powerpoint is using on Mac.
The general request flow is:
Browser -> AWS ALB (with stickiness enabled) -> Nginx -> Node
UPDATE
Looked into this further, and having tested other pages that use Socket.IO, I think the only difference in their setups and here is the ALB.
Even with stickiness enabled, the load balancer is clearly seen (in the logs) passing traffic between all EC2s. This leads me to believe the cookie they use is either not being set or not being passed with the requests.
First of all, based on this github issue it should be possible to open a websocket.
There might be a problem with using the unsecure ws://. I know that officejs rejects all requests to http:// and forces you to use https:// with a secure certificate. So they might do the same with WebSockets and force you to use wss:// with a valid certificate.
You can test this more easily in Power Point Online with Chrome. The addin is the same but you get much better error logging in the Devtools Console (hit F12). If it's asecurity issue there should be an error message indicating it.
I had the same issue and S.Freederle is correct. Now I'm able to use socket.io via ngrok to create a secure tunnel (HttpS) to connect to my server and emit the data to my client side in office add-in.
that's my first question here. After long research, I decided to ask for help...
So first I'll explain my scenario. I have some SOAP web services here. They're consumed by an .Net website. The .Net framework used is in version 4.0.
So my web services are configured to accept HTTP/1.0 protocol, due to .Net limitations. In spite of that, everything works fine if I access the service directly to Jboss AS(4.2.2 GA).
But, I have to make it work with Apache web server as the receptor of the request. Apache do a inverse proxy redirection to my service, so the site send requests to port 8080 (that Apache is listening) and send it to jboss that is expecting the request at port 18080.
In many tests, I confirmed that almost every service worked almost fine, sometimes they have the same failure. But one in particular don't work anyway, the request stopped at Apache with status 400 and empty value (the - after the 400) like that:
POST /xxxx/xxxx/xxxxx/MyService HTTP/1.1" 400 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; MS Web Service Client Protocol 4.0.30319.296)
The other requests that are processed have this value filled. I guess is the response size.
Please consider my regards. thanks
After great efforts at my company we discovered using an Sniffer(Wireshark) that we had two problems that let us to had the situation described in this problem.
First problem solved: .Net platform is configured to send by default an empty request. The first attempt failed so .Net was forced to automatically send a second request with authentication. So i figured out 2 requests before the Jboss response formed an http 400 error.
Second Problem solved:
After the other side solved thise previous problem configuring .Net properly, we tested again and the results were conclusive that no more requests was hitting Apache Http Server. - So there was a strong signal that we had something blocking this specific service. With the rocks in my hand, infrastructure people started to move their asses and somehow solved the problem. Mine frustration in the end is that they didn't said nothing about the possible correction. So "suddenly" the communication was restored..
So after all we made it! but with a bitter taste of defeat. Thank you all that supported me in this problem. []s
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....
I have an ASPX page. When the page is loaded there is code in the code behind that uses an API. The API makes an HTTPS call out to a third party, commercial web service. I am trying to troubleshoot why the API calls are not working properly. Apparently the API actually constructs an XML request that is sent out over HTTPS to the web service. I've been told by the support rep that I need to provide them with the XML that is being sent. The only way I can figure out how to get the XML is to use a tool like Fiddler to see what is being sent out. So how can I use Fiddler to see the contents of the XML request that is being sent from the server out to the web service? I am running everything directly on the server but all I am seeing is the GET request for the ASPX file itself. I am not seeing anything in relation to the HTTPS request that the server code is sending out to the web service. I have not used Fiddler much so I am hoping that maybe I just don't have it set up right to monitor that traffic.
Corey
After mucking around with it a bit I found this post: Why isn't fiddler capturing request when invoking XMLRPC from iis?. That seemed to do the trick! Basically it sounds like the default proxy settings in Win7 are on a per user basis. So I went in and changed the identity of the AppPool for my site to a local user (Administrator) and then it worked great. I started up Fiddler. Then I started up my ASP.NET app and then when I loaded the page I saw the request that went out to the web service from my code behind! Yay!