10

I've been working on a project for the last 6 months. For this project I have a glassfish server instance where a webservice is deployed. At the client side, I'm using JavaFX2.2 which does REST requests with Jersey (XML requests/responses, no JSON) with BASIC authentication.

When the user starts the program (JWS/JNLP), normally they just enter their credentials in an own made login window, press the login button and start working. Since 7u21 however, I got an extra Java "Authentication Required" pop-up for some reason (probably because of the changed security in 7u21).

Authentication required pop-up

To be sure it had nothing to do with compatibility issues between Java versions, I updated the server as well to 7u21, so:

  • Client: updated java from 7u17 to 7u21
  • Server: updated java from 7u09 to 7u21, adjusted glassfish asenv.bat file to use the new jdk

If I hit the cancel button in the "Authentication Required" window shown above, the program does start thou, but it does not run stable when doing requests:

java.io.IOException: stream is closed
file:/D:/NetBeansProjects/MIT_20130516/CL_KenoM/dist/CL_KenoM.jar!/GUI/cow/ListCow.fxml
  at com.sun.jersey.api.client.ClientResponse.close(ClientResponse.java:615)
  at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:570)
  at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:535)
  at com.sun.jersey.api.client.WebResource.handle(WebResource.java:696)
  at com.sun.jersey.api.client.WebResource.access$300(WebResource.java:74)
  at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:512)
  at DA.CowsClient.getCowsByUserId(CowsClient.java:96)
  at GUI.cow.ListCowController.initialize(ListCowController.java:728)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2152)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2028)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2744)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2723)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2709)
  at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2696)
  at Classes.Context.showContentPane(Context.java:186)
  at GUI.user.ListUserController.openAddData(ListUserController.java:389)
  at GUI.user.ListUserController.access$100(ListUserController.java:55)
  at GUI.user.ListUserController$8.handle(ListUserController.java:657)
  at GUI.user.ListUserController$8.handle(ListUserController.java:652)
  at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:69)
  at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:217)
  at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:170)
  at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:38)
  at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:37)
  at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92)
  at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35)
  at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92)
  at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35)
  at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92)
  at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:53)
  at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:33)
  at javafx.event.Event.fireEvent(Event.java:171)
  at javafx.scene.Scene$ClickGenerator.postProcess(Scene.java:3117)
  at javafx.scene.Scene$ClickGenerator.access$8600(Scene.java:3055)
  at javafx.scene.Scene$MouseHandler.process(Scene.java:3337)
  at javafx.scene.Scene$MouseHandler.process(Scene.java:3168)
  at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3123)
  at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1563)
  at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2265)
  at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:250)
  at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:173)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:292)
  at com.sun.glass.ui.View.handleMouseEvent(View.java:528)
  at com.sun.glass.ui.View.notifyMouse(View.java:922)
  at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
  at com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29)
  at com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:73)
  at java.lang.Thread.run(Unknown Source)

com.sun.jersey.api.client.ClientHandlerException: java.io.IOException: stream is closed

This error happens randomly when using a GET method (haven't tested with PUT or DELETE), in this case it was the getCowsByUserId() method:

public List<Cows> getCowsByUserId(int id) throws UniformInterfaceException {
    WebResource resource = webResource;
    resource = resource.path(java.text.MessageFormat.format("cows/user/{0}", String.valueOf(id))); //this is line 96
    List<Cows> list = resource.accept(javax.ws.rs.core.MediaType.APPLICATION_XML).get(new GenericType<List<Cows>>() { });

    return list;
}

The funny part is, when I start the program through Netbeans or with the .jar file instead of .jnlp, everything works as intended (no extra authentication pop-ups, no errors)... so this must have to do something with Java Webstart I guess?

EDIT 28 May 2013:

I did some further research by comparing the java console tracing/debugging logs from 7u17 and 7u21. I noticed the following in the 7u21 log:

security: Trust for: http://<url>/lib/jersey-core-1.17.jar has ended: Thu Jan 01 01:00:00 CET 1970
security: Validate the certificate chain using CertPath API
security: SHA-256 finger print: <bunch of chars>
security: The certificate hasnt been expired, no need to check timestamping info
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Start comparing to jurisdiction list with this certificate
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
security: JAVAWS AppPolicy Permission requested for: http://<url>/lib/jersey-core-1.17.jar

The first line does not show up in the 7u17 log, so it has to do something with signing the jars? It shows for multiple jar files the same thing. When building the project, everything gets signed with an own made keystore, is this the big problem? Does this mean that JNLP will only work decently if the jars are signed with a certificate created by a trusted CA (which isn't free ofcourse)?

EDIT 04 June 2013:

I bought myself a code signing certificate from GlobalSign, installed it onto my machine. Converted the PFX certificate file to a Java Key Store (JKS) and used that one to sign my jars (in Netbeans). Afterwards verified the jars and all seems to be ok. However, I updated the files on the webserver, launched the program through the JNLP file but still the same behavior.. time to get desperate!

EDIT 06 June 2013:

Alright, started a different approach. As a matter of test I tried to fetch XML data by using HTTPUrlConnection() instead of Jersey:

I get the same 'Authentication Required' window when doing a http GET request when using 7u21. With 7u17 I get the XML response. Still nobody got a clue what could be wrong? Could this have something to do because I use BASIC authentication? Could this be server related? Could this have something to do with the JNLP file? The more answers I search for this question, the more questions I have it seems :)

Perneel
  • 3,317
  • 7
  • 45
  • 66
  • Did you resolve this? I tried following the advice in the accepted answer by dennis-the-menace to no avail. Did you change anything server-side regarding cache control? – aioobe Feb 08 '14 at 04:57
  • Hi aioobe, you can find the answer here: http://stackoverflow.com/questions/17278303/basic-authentication-fails-with-glassfish – Perneel Feb 10 '14 at 08:59

3 Answers3

3

My answer to your follow-up question should also answer this question.

In short: Java Web Start caches HTTP responses by default in JDK7 and you have to set the Cache-Control header to "no-cache, no-store" on your client request and on the responses by the Jersey REST service.

Community
  • 1
  • 1
dennis-the-menace
  • 121
  • 5
0

The answer is here :

Java Web Start keeps asking to authenticate

I don't know why you didn't experience this behaviour before. It may have been a security issue in previous versions of Java Web Start or previous versions of your browser.

I don't think the IO error is related.

Community
  • 1
  • 1
Eric Citaire
  • 4,355
  • 1
  • 29
  • 49
  • 1
    It's not really the same because I do not have to pass the website authentication (there is none) to Java. All the authentication happens in the program itself. So, the user just clicks a hyperlink to the JNLP file, the program launches through JWS and the user get to see the (own made) login window. He or she enters the credentials and continues working. I never had an extra Java Authentication window before, so that's why I'm all confused :) – Perneel May 25 '13 at 16:27
  • More tests seems to point that it has something to do with 7u21. Previous versions of Java do not have this issue it seems... Any ideas? – Perneel May 26 '13 at 09:17
  • 1
    Not sure, but this may be related to your issue : http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html (7u21 seems to introduce some security related changes). – Eric Citaire May 26 '13 at 09:31
  • Thanks for pointing that out, however I don't have a clue to solve this thou. Added some extra findings to the first post. Does everything have to be signed by trusted CA's? – Perneel May 27 '13 at 14:18
  • New findings added, 6 June 2013. – Perneel Jun 06 '13 at 14:04
0

These type of problems often can be solved by browser settings:

IE -> add domain to your list of 'intranet' zone sites; Chrome -> add exception to list of domains where you want to allow unsandboxed plugin access.

If you are in a managed Enterprise environment forward the problem to your internet security staff as these type of settings are usually disabled for the plebs.

As explained for IE:

If access from a plugin is requested from outside the 'intranet' zone, it is automatically regarded not secure enough to pass on any username/password information to the requesting domain. Hence the login pop-up to provide it with the credentials from the client. Adding the domain to the 'intranet' zone will resolve this issue in most cases.

Leo
  • 64
  • 3