We have client-server application and we launch the client application using java web start.
While trying to open client application, it first reads a token file from https url (for SSO) and later opens another HTTPS url.
tokenUrl = new URL(protocol, nodeIpAddress, port, tokenFile);
URLConnection con = tokenUrl.openConnection();
The openConnection() is throwing below Exception:
java.lang.NoClassDefFoundError: Could not initialize class sun.security.mscapi.SunMSCAPI
Could any one please help what is the exact issue here and please provide necessary workarounds.
Thanks,
Sourav
That class is an implemention of the Microsoft Crypto API, and it was added to the JRE only in Java 6 - so I suspect that it's a JRE version issue.
Related
I´ve set up a samba server on a Mac with OS X El Capitan.
Then, configured my java project to access this server using jCifs library but I get this error:
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password
My code is:
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("domain","username","password");
String path = "smb://ip/filepath";
SmbFile file = new SmbFile(path, auth);
The username I used is the owner of the account in which I set up the server in the Mac and the password is correct.
I tried to access from another Mac and from an android device, both in the same network. I Also tried creating another user account in the server, with no luck.
In google, most of the cases belong to other OS. Besides that, my configuration seems fine.
Any idea? Thanks in advance.
After a deeper research, I found a post in which is told that the smb protocol implementation seems to be broken in OS X (link here: http://www.tweaking4all.com/os-tips-and-tricks/macosx-tips-and-tricks/smbup-mac-os-x-smb-fix/).
The server was set up using the configuration tool provided by the operating system so I tried to reconfigure the server with the same settings than before using other tool (SMBUp) and now I can connect without any problem without having changed the code.
Hi all Java/Applet gurus,
I've stumbled upon an interesting problem with the latest JDK build (1.8.0_b26).
When running Sandbox Java Applet with the latest JDK, from within Java code we try to connect back to the server with a different protocol - instead of original HTTPS we use WSS (secured Websockets connection, we use third party Websockets Client Java library). As the result, JVM tries to retrieve crossdomain.xml file from the server. The problem is, that the file is retrieved using HTTP (and not HTTPS) protocol.
For example, in our case the server IP is 192.168.1.1, the applet is loaded over HTTPS default port (443). Using trace level 5 in Java console we see that the crossdomain.xml is retrieved from http://192.168.1.1:443. And of course it doesn't work because the server listens only for HTTPS connections on port 443 (and not HTTP).
On the other hand, when we use HTTP protocol and open new WS (unsecured Websockets connection) to the server, the problem doesn't appear, because crossdomain.xml is retrieved from http://192.168.1.1:80 and it is completely correct.
As the problem was further investigated, we've made few more observations:
It is possible to provide alternative location of crossdomain.xml file using jnlp.altCrossDomainXMLFiles Java VM parameter. We've never succeed to make this parameter work for us though (tried both in java_arguments list and as lone applet parameter). The possible reason might be that the parameter should be used only with Webstart application (although it is not written specifically in specs).
While establishing Websockets connection, the connection stack trace is as follows:
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:787) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
at
sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1429)
at java.security.AccessController.doPrivileged(Native Method) at
java.security.AccessController.doPrivileged(AccessController.java:713)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1428)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown
Source) at
sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown
Source) at
sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)
So we looked at the latest publicly available source code of CrossDomainXML.java class (back from 2010 though). And from the code it is evident, that http connection is always used while retrieving crossdomain.xml file from server, regardless what is the original browser connection.
So the questions are:
Might it be a JDK bug or the strict usage of HTTP for crossdomain.xml is by design?
Is jnlp.altCrossDomainXMLFiles JVM parameter supported inside Sandbox applet?
Is there a way access the latest version of com.sun.deploy.net.CrossDomainXML.java source code to get a full picture of what is going on?
Thank you very much in advance.
Best regards,
Mark
in order to get rid of the http://myhost/crossdomain.xml request, there is nothing you can do except adding something like this into your java.policy file:
permission java.net.SocketPermission "myhost:1024-", "connect, resolve";
You can restrict that to a specific certificate signer in order to enforce this policy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission
We use it like this in an applet early in the init-process (applet constructor) and it works:
try
{
System.setProperty("jnlp.altCrossDomainXMLFiles", //
"http://www.some-domain.de/crossdomain.xml" //
+ ",https://www.secure-domain.de:8443/crossdomain.xml" //
);
}
catch (Exception e)
{
e.printStackTrace();
}
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);
URL u=new URL("telnet://route-server.exodus.net");
This line is generating :
java.net.MalformedURLException: unknown protocol: telnet
And I encounter similar problems with other URLs that begin with "news://"
These are URLs extracted from ODP, so I don't understand why such exceptions arise..
Issue
Java throws a MalformedURLException because it couldn't find a URLStreamHandler for that protocol. Check the javadocs of the constructors for the details.
Summary
Since the URL class has an openConnection method, the URL class checks to make sure that Java knows how to open a connection of the correct protocol. Without a URLStreamHandler for that protocol, Java refuses to create a URL to save you from failure when you try to call openConnection.
Solution
You should probably be using the URI class if you don't plan on opening a connection of those protocols in Java.
Sounds like there's no registered handler for the protocol "telnet" in your application. Since the URL class can be used to open a InputStream to URL it needs to have a registered handler for the protocol to do this work if you're to be allowed to create an object using it.
For details on how to add handlers see: http://docs.oracle.com/javase/7/docs/api/java/net/URLStreamHandlerFactory.html
You're getting that error because java doesn't have a standard protocol handler for telnet.
The simple answer is that it only does recognize certain protocols, and the remainder of the infinity of protocols is not recognized.
I am using following code to retrieve response code from https based urls, but when i run a prog it just hangs cont.
code:
import java.net.;
import javax.net.ssl.;
import java.io.*;
class Https2
{
public static void main(String args[]) throws Exception
{
URL u = new URL("https://myurl");
HttpsURLConnection hc = (HttpsURLConnection)u.openConnection();
hc.setConnectTimeout(3000);
hc.setReadTimeout(5000);
System.out.println("Response Code: " + hc.getResponseCode());
hc.disconnect();
}
}
How can make successfull connection to Https urls ?
any help or ideas will be well appreciated.
Thanks
Don't know if it helps but I've never had much joy with the JDK HTTP classes and have typically wound up using the Jakarta Common HTTP Client API (http://hc.apache.org/httpclient-3.x/).
I tried the attached sample with https://mail.google.com/mail/, and it worked flawlessly on linux and Mac OS X.
The authentication of the server is required by default. You need to set the javax.net.ssl.trustStore system property as the name of a keystore containing the server's certificate.
BTW, it's a good idea to catch and print the exceptions to help diagnostics.
https://mail.google.com/mail/ works on my Windows XP box. Maybe your windows firewall settings does not contain the java.exe as exception? Or the site you want to connect to uses HTTP Basic Authentication over the HTTPS connection.
Or the site needs you to identify yourself with a certificate as suggested by others?
Edit: Try your code without the timeout parameters. HTTPS connection and handshake is usually slower than a regular HTTP call. Your connection might time out due this before it can read the requested data.
I thing hc.setConnectionTimeout() might not even work because when you get to that point you already have a working connection according to the javadoc.