I have an Application Client deployed on a local Glassfish 4.1 with Java 8u20 installed. Now whenever I try to start the client on the localhost (same machine) using Java Web Start it gets blocked by Java Security with the message:
Location: http://localhost:8080
Reason: The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.
I added localhost to the Exception Site List with following entries:
file:///
http://localhost
http://127.0.0.1
http://localhost.localdomain
then I even imported the Glassfish self-signed certificate as a Trusted Certificate in the Java Control Panel. Finally I enabled Mixed code and disabled certificate revocation checks in the Control panel. But still my application gets blocked.
As the medium Security level is not available anymore, what can I do further?
If you use a javaws from a java 1.7 u25 or earlier, your application client will work.
I have the same problem with Java8u31. My application client won't start with a javaws later than u25, but if is use u25 or under it will.
So, I use u25 to start the application client, but the application runs in the java 1.8 u31 environment.
I also cannot get the exception site list to work. I starting to think their is a bug in java here.
I tried to replace the s1as certificate in glassfish per these instructions to no avail. https://blogs.oracle.com/quinn/entry/glassfish_java_web_start_and
Not sure that it is possible to have glassfish automatically sign an application client with the new security restrictions!
Related
I have a Java jetty-based web application that I am migrating from HTTP to HTTPS.
I was experiencing difficulty connecting to the application over HTTPS - the request would just hang and eventually timeout.
I then set the JVM option -Djavax.net.debug=all to try and debug what was going on and to my surprise I was able to connect over HTTPS.
To make sure I was not going mad I then removed the option and once again could not connect over HTTPS.
This is very puzzling to me - I thought this option would just affect logging behavior, not actual application behavior. Does anyone have any idea what could be going on here?
It was a bug with the version of jetty I was using (9.4.14.v20181114), upgrading to a newer version (9.4.15.v20190215) allowed me to connect without setting -Djavax.net.debug=all
It is still unclear to me why setting -Djavax.net.debug=all made it work.
I have a weblogic 10.3.6 installed in windows server 2008 R2 64-bit with Java 7 update 111. With in weblogic server I have 4 manged server running many java applications.
I have new client web-services application need to be deployed in one of the 4 manged server and this application require TLS1.2 as requested by third party services provider application. For that purpose, I am setting the following property in client application code like System.setProperty("jdk.tls.client.protocols", "TLSv1.2");
Question:
Will the statement System.setProperty("jdk.tls.client.protocols", "TLSv1.2"); change the protocol for only manged server where the application is deployed ? Or it will be for all application servers available within weblogic ?
If this command change the protocol for all manged servers, then this is a problem since other applications may get affected. What is the solution in this case and what is the right action to be taken to enable the required SSL protocol for that specific application without affecting other running applications ?
It should affect all managed servers on that box (probably after the nodes are restarted)
TLS is compatible with SSL - just not with insecure handshake protocols (which you should have stopped doing years ago) For more information, see: Modifiying Weblogic Server to use TLS
I’m using glassfish 3.1.2 on Red Hat Enterprise Linux Server release 5.7 (Tikanga). Glassfish has been installed as part of a piece of bigger software (that I’m developing). It used to work correctly in the past.
I can issue a ‘start-domain’ command. This one will work correctly and glassfish will start. I can see the process and the glassfish admin web console is working fine. However, the command ‘list-domain’ reports my domain as not running. The command ‘stop-domain’ will fail reporting the domain1 as already stopped. This prevents my software to run properly.
As far as I know, nothing has changed on that system. There is no exception/error in the log. I already search the internet for description of similar behaviour. I ensured the embedded firewall (the one coming with the OS) did not prevent the communication. I removed the expired certificate (just in case). I have no idea on what I could do next.
What could I check? Any help appreciated. Add a comment if you need specific details and I will update the question.
Answer to unwichtich's questions:
absolute path to jvm using an absolute path to the admin-cli.jar: /.../java -Duser.home=... -Duser.language=en -Dhttps.protocols=TLSv1.2 -jar /.../glassfish/modules/admin-cli.jar --terse --port 23992 --user admin --passwordfile /.../passwordfile list-domains
There are two lines in the /etc/hosts. The first with the ip mapping to the hostname. The second with 127.0.0.1 mapping to loopback and localhost
My software includes some command line utilities that need to perform operation on Glassfish (like start-domain, stop-domain, list-domains,...).
I am using Eclipse 3.5 along with JDK 1.6.0_23 (both on Laptop and desktop) within my organisation. The proxy server uses Windows domain authentication to pass through request.
While adding update sites within Eclipse available on Laptop, I could see that Eclipse is able to connect the site and doesn't throw authorisation exception. I have set the Active Provider in Network Connections as Native. I haven't configured my credentials in eclipse anywhere and it communicates with Proxy server smoothly.
I have similar settings on my desktop machine, but it throws Proxy Authorization exception. There is no clue in Error log. But it does displays a information indicating
System property http.proxyHost is not set but should be XXX.XXX.XXX.XXX.
Similar messages do appear for http.proxyPort and https as well. I don't want to explicitly enter my credentials in Eclipse and hence looking for clues as why similar settings are behaving differently in these environments.
I had the same problem with eclipse luna. I tried this link
( http://javarevisited.blogspot.com/2014/01/eclipse-not-able-to-connect-internet-market-place-configure-proxy-settings.html ) and it helped me resolve the problem!
I've being trying to setup my java application that connects to a local queue manager in MQ7 without a WebSphere Application Server installed on my machine in binding mode. Without specifying the host in the .bindings file, running my application will throw an java exception somewhere along the lines of:
com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ0018:
Failed to connect to queue manager 'TBUKKKNN' with connection mode
'Client' and host name ''. Check the queue manager is started and if
running in client mode, check there is a listener running. Please see
the linked exception for more information.
Although documentation for WebSphere MQ has explicitly denied possibility of connecting to MQ7 without WAS installed on same machine, my colleagues are very confident that there are workarounds for this.
Much appreciated if anyone could help me with this issue. Or let me know if more clarification on my question is required.
I wrote an article a while back that explains how to do this so I'm a little puzzled about any documentation stating that it can't be done. Not only is there a "workaround" but it is officially supported and the sample programs that come with the WMQ Client install media include several that use Java and JMS but do not use a Java EE server. If for some reason you just grabbed the jar files instead of installing the vendor distribution, you can download it for free to get the samples. The v7.0 client is here and the v7.1 client is here. Also, make sure to use the version of the docs that matches your client version. The v7.0 Infocenter is here and the v7.1 Infocenter is here. Any client version can connect to a v7.0 QMgr, by the way.
Anyway, your error message indicates that your Connection Factory transport type is still set to Client. You'll need to change it to BIND. The properties are described here. The landing page with the list of all the properties of all the administered objects is here.
Change to cf.setTransportType(MQCNO_STANDARD_BINDING); ...that should work
cf.setTransportType(WMQConstants.WMQ_CM_BINDINGS);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_BINDINGS);