I have an app with Third Party payment system. Once the payment is successful success response is sent back to the app. Recently we have migrated the app to a new server where the call to the Third party payment system is successful but for updating at our end the third party is facing an error as below:
An HTTPPost.postRequest.IOException [Error when writing data to url.] exception is thrown.
The third party is calling a POST method with the transaction details to update the status at our application end.
When I tried to hit the URL with the transaction details with a simple HTML page from the browser it was successful.
Can anyone help me in the solving the above error?
Is there any configuration that's missed while migrating the app to the new server?
The app is built in Java using the Stripes Framework.
1.Client data cannot be appended to URL if it is POST request.
It can be done only if it is GET request.
2.With most of the Browsers you can track the Network activity. And also check for URL object validity
URL url = new URL("http://www.yourUrl.com/");
HttpURLConnection con = (HttpURLConnection)url.openConnection();
con.setRequestMethod("GET");
con.connect() ;
OutputStream os = con.getOutputStream();
int check= con.getResponseCode();
3.HTTPPost.postRequest.IOException can also occur if there is anything wrong with server. Check if the server is compatible to receive the data from "Third Party payment system"
Provide more details with stacktrace so that you can receive quick and more precise answers.
Hope this helps!!
Related
I have an endpoint to be tested using RestAssured. The same endpoint is working fine while opening it in browser/Postman. But, while trying to test the same using RestAssured,
I am getting Operation Timed Out Error.
I had to connect to proxy to make that end point working in browser. used the same proxy in the rest assured also.
Sample Code below:
given().proxy("My_Proxy_URL_HERE",8080).when().get("My_API_URL_Here").then().log().all();
I am getting the response as
"Operation Timed Out" with Status Code 503.
I need your suggestion, what could be the possible issue, how to debug etc. Any suggestion is appreciated. Thanks in advance.
There can be many reasons for this behavior:
The address is just wrong and given there is some load balancer/proxy it can be configured to wait for a certain period of time and then respond with 503 status code.
Note, 503 is not a "request timed out", but "Service Unavailable".
The request url is good, but the request lacks some headers so that the load balancer/proxy won't be able to route the request to the required server.
How to check this? there exist tools that can come handy in this situation:
Check the access logs of the load balancer/proxy and even of your server if its possible - and see the request.
If it doesn't help, try to compare requests coming from rest-assured vs regular request. You can use tools like Burp for example, there are others, or you can even roll your own.
The idea is simple:
Start the "interceptor" on some port of your local computer (say, 9999 for example)
Configure the interceptor to forward all the requests to proxy of your choice (identified by URL - My_Proxy_URL_HERE and port 8080).
Now rest-assured must call localhost:9999 and the request will be intercepted by this tool. You'll be able to inspect its contents - headers, body, http method - everything.
Do the same for browser request and compare.
Description - There is an intranet web application hosted on a WebSSO server. When I manually type in the URL in a browser, the server recognizes me as a valid user and lets me into the website. The authentication is automatically done by using my Windows credentials. I do not have to fill out a login form or anything like that.
Problem - I am trying to make a HTTP GET request to the same URL. The server does not recognize me as a valid user and I get a 401 error.I am trying to do what is described here
My research so far - Looks like my Java session is not the same as my browser session. I looked at my browser's request headers. These headers automatically have a CTSession in the cookie when I manually navigate to the URL(CTSession is unique for every login and is generated dynamically). How do I make the server recognize my Java session as a valid one. What kind of headers do I need in my HTTP GET request? I have already tried the following and it did not work. I get the 401 error
1- con.setRequestProperty("Authorization", new String(Base64.encodeBase64(("username" + ":" + "password").getBytes());
2- Opening a connection to a URL of the below format.
url = "https://fullPath/j_security_check?j_username=username&j_password=pwd
I have a bit of Java code to download url data that is plagued by the error in the title. Sometimes it works, most time it fails. Has anyone come across this:
URLConnection urlConnection = url2search.openConnection();
urlConnection.setRequestProperty("User-Agent","Mozilla/5.0 ( compatible ) ");
urlConnection.setRequestProperty("Accept","*/*");
urlConnection.setDoInput(true);
urlConnection.setDoOutput(false);
try{
reader = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
}catch(Exception r)
{}
Now it fails consistently at the reader line with:
java.io.IOException: Server returned HTTP response code: 520 for URL:
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
I can copy the url in to the search bar and it works fine. And as yet my web research on this topic has proved fruitless. Any suggestions?
An HTTP error code between 500 and 599 indicates a server failure. It could be at the requested document's origin server, or at a proxy server between the client and the origin server.
Code 520 itself is not documented by any of the HTTP specifications, so its specific meaning is unclear. If that code is being generated by a CloudFlare reverse proxy between your client and the origin server, however, then it signals a generic, unspecified connection error between the proxy and the origin server.
Any way around, the problem is basically external to your client. It may be that there is something about your request properties that tends to cause the server chain to fail as you observe it to do, but to debug it you need either to analyze the server logs and software, or else to reverse-engineer its behavior. If the problem is not exhibited in conjunction with your browser, then you could consider capturing the request/response involving your browser to see how it differs from the request/response involving your Java client.
Try bringing your user agent string up the latest.
See here: https://www.whatismybrowser.com/guides/the-latest-user-agent
I am developing an android application and want to connect to a REST service using URLConnection. The resource is protected using Digest Authentication. I can successfully access the REST service via the browser. I do not want to use HttpClient because URLConnection is the more current way to connect for the future.
But when I try to access the resource via the code below, I get a 401 Error with an java.io.FileNotFoundException. I have researched this thoroughly but no success, solutions appreciated.
Note: My REST service has been developed using Grails, I am running this code in the android emulator with code developed in Eclipse on the windows 64 bit OS.
CODE
URL myurl = new URL("http://10.0.2.2:8080/MyREST/customers");
HttpURLConnection myurlConnection = (HttpURLConnection) myurl.openConnection();
String basicAuth = "Basic " + (Base64.encode(userpass.getBytes(),android.util.Base64.DEFAULT)).toString();
myurlConnection.setRequestProperty ("Authorization", basicAuth);
try {
int responseCode1 = ((HttpURLConnection) myurlConnection).getResponseCode();
Log.i("MyLongOperation", "Check connection" +Integer.toString(responseCode1) );
InputStream in = new BufferedInputStream(myurlConnection.getInputStream());
readStream(in);
}
finally {
myurlConnection.disconnect();
}
I have also tried setting authentication at a global level with no effect
Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(username, password.toCharArray());
}
}
);
I have referred to this article - with no success. Connecting to remote URL which requires authentication using Java
If the resource is protected by "Digest" then sending a "Basic" authorization scheme in your code will not work because the server would not recognize it.
Secondly, by using a "preemptive" authentication, setting the Authorization header w/o it being requested is kind of a security hole. You will be sending information to the server that it has not requested.
Thirdly, the "Authenticator.setDefault" most likely will not be requested as there was some significant back-and-forth caused by MicroSoft's implementation of HTTP digest authentication (YMMV may vary on my recollection of this). As such, Sun/Oracle decided to leave this behavior disabled by default as per this document.
That said, you may be better off looking into utilizing the Apache HTTP client bundled with Android to do this. There is a bundled implementation Digest Authentication included. There is an example of "preemptive" digest authentication located here.
Couple of caveats to be aware of:
Pay CLOSE attention to the "HttpHost" stored in "target" - this MUST MATCH EXACTLY the host name, protocol port, and protocol scheme used in the URL being retrieved.
The example provided is for HTTP Client 4.2.x. I am not 100% sure of the version included in Android but you should be able to locate working examples.
Update Submitter has provided additional comments with regard to the statement that it is recommended by Google to use the HttpURLConnection with articles here and here.
While I trust the statements made by Tim Bray with regard to the reasoning as to why you should be using the provided HttpURLConnection object for performing these calls, I do not agree that they should be immediately accepted on face value.
There is no indication as to the level of support of digest authentication provided by the implementation in Android. As I mentioned earlier, the HttpURLConnection does not support immediately as it has been known to be buggy.
If you are decided that you are going to use HTTP Digest Authentication, regardless of the fact that it has been deemed unstable by the majority of the community, I would attempt to set the following system properties in your application as EARLY as possible during the Android lifecycle:
http.auth.digest.validateServer="true"
http.auth.digest.validateProxy="true"
By doing so, this should enable the digest authentication scheme.
I am, again, going to re-iterate that the Apache HTTP Client bundled with Android was developed and designed specifically to address short-comings of the basic Java HttpURLConnection, providing much a much broader and robust client for dealing with HTTP(s) based data streams.
I would recommend trying a couple of things as well, see if you can configure your container to provide "Basic" authentication protection. The other, more complex option, would be to possibly provide X.509 Certificate Based authentication.
I hope that this clarification helps you get to your goal.
change
'Base64.encode ...'
to
'Base64.encodeToString ...'
I have a Gingerbread Android application that I'm porting to ICS. This application communicates with a web server sending HTTP POST. My application runs fine on Gingerbread. However, I have been experiencing problems after porting it to ICS. I found out that the POST requests my application is sending are actually changed to GET.
The funny thing is, Android actually reports that POST is indeed used.
URL oURL = new URL(sURL);
HttpURLConnection oHTTPConnection = (HttpURLConnection)(oURL.openConnection());
oHTTPConnection.setDoInput(true);
oHTTPConnection.setDoOutput(true);
oHTTPConnection.setRequestMethod("POST");
// set headers...
int nResponse = oHTTPConnection.getResponseCode();
String sMethod = oHTTPConnection.getRequestMethod(); // Returns "POST"
However, the server would say otherwise. I modified the web server application to check the request method it receives and then put this value in the response body it sends back to my Android application. And what I receive on my Android application is "GET".
I have tried using HttpClient with HttpPost but I get the same issue.
As I mentioned, I didn't have this problem in Gingerbread. Also, I've read from another thread here a similar (but opposite) problem that also only happens in ICS: Android 4.0 ICS turning HttpURLConnection GET requests into POST requests.
Has anyone else experienced this? Can anyone help me solve this?
Thanks in advance!
Rai
Try follow this answer: https://stackoverflow.com/a/8799198/372076
I've found that pre-ICS one could get away with making a body-less
POST without providing a Content-Length value, however post-ICS you
must set Content-Length: 0.
Don't know if you already found a fix for this, but i was having the same problem and just found a work around. In my case it was an issue on server's side with Apache's redirection. I was doing:
Url url = new Url("http://aaaa.bbbb.com/");
Changed to:
Url url = new Url("http://aaaa.bbbb.com/index.php");
Somehow the redirection was turning my POST into a GET with no parameters.