Authentication required window popping up after 7u21 update

java rest jersey code-signing jnlp
Perneel picture Perneel · May 18, 2013 · Viewed 8.2k times · Source

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 :)

Answer

dennis-the-menace picture dennis-the-menace · Aug 21, 2013

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.

Related questions

How to access parameters in a RESTful POST method

My POST method looks like this: @POST @Consumes({"application/json"}) @Path("create/") public void create(String param1, String param2){ System.out.println("param1 = " + param1); System.out.println("param2 = " + param2); } When I create a Jersey Client in Netbeans the method who …

Read More
Jersey client: How to add a list as query parameter

I'm creating a Jersey client for a GET service that has a List as query parameter. According to the documentation, it's possible to have a List as a query parameter (this information is also at @QueryParam javadoc), check it out: …

Read More
what's the correct way to send a file from REST web service to client?

I've just started to develop REST services, but I've come across a difficult situation: sending files from my REST service to my client. So far I've gotten the hang of how to send simple data types (strings, integers, etc) but …

Read More