My Java application runs through Java web start and I'm downloading a file from a web server using browser's session ID. It works fine on previous to Java 7 update 51 but failed on Java 7 update 51. Here is the code. There is no issue on HTTP URL. Problem only occurs with HTTPSURL.
When Java application makes connection with the HTTPS URL, web server not considering URL as a valid URL.
URL webURL = new URL(m_url);
conn = webURL.openConnection();
conn.setRequestProperty("Cookie", cookie);
Cookie has valid session ID. Again this works fine on Prior to Java 7 update 51.
Anything has changed on Java 7 update 51 related to HTTPS URL Connection?
It seems to be Java Web start sends empty HTTPS request before sending actual HTTPS request. Again this happens only after Java 7 update 51.
Root cause for empty HTTPS request is below line of JNLP code.
**<jnlp codebase="https://20.107.21.23:443" spec="1.0+">**
Found solution in two ways.
Changes in web server code
When web server receives empty HTTPS request, do not set cookie for that request.
Change codebase attribute value in JNLP file as below
**<jnlp codebase="https://*20.107.21.23:443" spec="1.0+">**
or
**<jnlp codebase="https://20.107.21.23:443/*" spec="1.0+">**
Related
My app is getting this error when accessing a HTTPS resource (using appengine-java-sdk-1.9.63):
javax.net.ssl.SSLHandshakeException: Could not verify SSL certificate for URL: https://some.where/
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.convertApplicationException(URLFetchServiceImpl.java:175)
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:45)
at com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler$Connection.fetchResponse(URLFetchServiceStreamHandler.java:543)
at com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler$Connection.getInputStream(URLFetchServiceStreamHandler.java:422)
at com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler$Connection.getResponseCode(URLFetchServiceStreamHandler.java:275)
at org.jsoup.helper.HttpConnection$Response.execute(HttpConnection.java:656)
at org.jsoup.helper.HttpConnection$Response.execute(HttpConnection.java:629)
at org.jsoup.helper.HttpConnection.execute(HttpConnection.java:261)
at org.jsoup.helper.HttpConnection.get(HttpConnection.java:250)
What can be done so GAE would not check of SSL since in my current purpose for the app, it does not care if it connects via HTTP or HTTPS, so in my case I just want to disable SSL check.
Update:
I am running the application from Windows (Linux does not throw the error above)
Already I have modifiied the dev_appserver.cmd like this:
java -Ddeployment.security.TLSv1.1=false -Ddeployment.security.TLSv1.2=false -cp "%~dp0\..\lib\appengine-tools-api.jar" ^
com.google.appengine.tools.KickStart ^
com.google.appengine.tools.development.DevAppServerMain %*
Also in the application itself this is set:
FetchOptions fetchOptions = FetchOptions.Builder.doNotValidateCertificate();
HTTPRequest request = new HTTPRequest(getUrl, HTTPMethod.GET, fetchOptions)
What could be wrong with Windows that it throws the error whereas in Linux there is no problem?
The solution that worked for this problem is to update the JDK of the machine. Then after upgrading from Java 7 to Java 8, the SSLHandshakeException is not being thrown anymore.
Thus, problem solved.
My company’s web application is using GWT both for front-end and back-end and we’d like to remove GWT from the project. Our current objective would be to make a new login page in Angular2 using the existing GWT back-end.
The main problem we encounter at the moment is that all the requests coming from outside the current GWT front-end seem to be intercepted/blocked and don’t return anything. I’m currently using Postman to make GET requests from the server.
Here is the URL I’m calling : http://localhost:9997/RestServer/api/users/1.
Postman’s response:
« Could not get any response
There was an error connecting to http://localhost:9997/RestServer/api/users/1. »
GWT Development Mode’s console returns an error:
[TRACE] Connection received from 127.0.0.1:60296
[ERROR] Unrecognized command for client; closing connection
com.google.gwt.dev.shell.BrowserChannelException: Invalid message type 71
at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1135)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:248)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222)
at java.lang.Thread.run(Thread.java:745)
Have you got any idea why my requests are intercepted? Why I can't even receive a http response?
If you need more informations to answer just ask for it.
Port 9997 in the old dev mode is not an HTTP server. This is the port on which the legacy browser plugin (unsupported in modern FF and Chrome due to breaking changes in those browsers) would connect to run Java code and enable remote debugging, hotswapping, etc.
Instead, you need to connect to the HTTP port, which is 8888 or 8080 or something like that.
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
Folks,
We have a Java Applet communicating with the server through a BigIp Load-Balancer. The Java Applet is using an HttpURLConnection and the communication protocol is https.
The Load-Balancer implements a cookie based persistence policy to maintain session affinity.
This all works fine when the Java Applet using Java 1.5, 1.6 and early versions of Java 1.7.
Somewhere around Java 1.7.0_21 something went wrong with the Java Applet and now when we open HttpURLConnection for the 2nd time and on, the load balancer does not pass the request to the server but instead replies with the same response sent for the 1st request from the Applet as if thinking the request is for static content that can be cached.
Any ideas what has changed in recent versions of Java with respect to HttpURLConnection ?
You may want to check that you are properly negotiating an SSL connection. You can do this two ways: create an iRule to log to /var/log/ltm:
when HTTP_REQUEST {
log local0. “Requested hostname: [HTTP::host] from IP: [IP::local_addr]”
}
Turn on SSL debug logging:
tmsh modify /sys db log.ssl.level value Debug
If you are failing to negotiate SSL, you will not see anything logged from the iRule, but should have an answer as to why you are failing to handshake. Most often you need to adjust your cipher string.
Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.
Note: The client works on my Windows workstation.
I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
the server returning with a 500 status code
On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".
My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.
Any help would be greatly appreciated...
UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..
Some references:
Java HTTP Authentication
Blog showing Java Authenticator Impl
A while back when i had this problem, i ended up using a scheme created by somebody else.
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
Worked for me when i had to get image files from and iis server with ntlm.
Snippet using the code above..
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
HttpClient client = new HttpClient();
client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
GetMethod get = new GetMethod(strImageFile);
get.setDoAuthentication(true);
client.executeMethod(get);