Wymagane okno uwierzytelniające pojawiające się po aktualizacji 7u21

Question

Pracowałem nad projektem przez ostatnie 6 miesięcy. W przypadku tego projektu mam instancję serwera Glassfish, w której wdrożono usługę sieciową. Po stronie klienta używam JavaFX2.2, która wysyła żądania REST z Jersey (żądania XML/odpowiedzi, bez JSON) z uwierzytelnianiem BASIC.

Gdy użytkownik uruchamia program (JWS/JNLP), zwykle po prostu wpisuje swoje dane logowania w własnym oknie logowania, naciśnij przycisk logowania i zacznij działać. Jednak od 7u21 otrzymałem z jakiegoś powodu dodatkowe okno "Wymagane uwierzytelnienie" Java (prawdopodobnie ze względu na zmienione zabezpieczenia w 7u21).

Aby mieć pewność, że nie miał nic wspólnego z problemów z kompatybilnością pomiędzy wersjami Javy, I uaktualniony do serwera, a także do 7u21, więc:

• Klient: zaktualizowane java z 7u17 do 7u21
• Serwer: zaktualizowane java z 7u09 do 7u21, skorygowany plik GlassFish asenv.bat do korzystania z nowego JDK

Jeśli uderzę anuluj guziku n pokazano okno „Authentication Required” powyżej, program zostanie uruchomiony ty, ale to nie działa stabilny podczas wykonywania żądania:

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 

Ten błąd zdarza się przypadkowo, gdy za pomocą metody GET (nie testowałem z PUT lub DELETE), w tym przypadku był to() metoda getCowsByUserId:

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; 
} 

Najśmieszniejsze jest to, kiedy uruchomić program przez Netbeans lub z pliku .jar zamiast .jnlp, wszystko działa zgodnie z przeznaczeniem (brak dodatkowe wyskakujące okienka uwierzytelniające, brak błędów) ... więc to chyba musi coś zrobić z Java Webstart?

EDIT 28 maja 2013:

zrobiłem kilka dalszych badań przez porównanie konsoli Java dzienniki śledzenia/debugowania z 7u17 i 7u21. Zauważyłem, że po w dzienniku 7u21:

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 

Pierwsza linia nie pojawiają się w dzienniku 7u17, więc musi coś zrobić z podpisaniem słoiki? Pokazuje dla wielu plików JAR to samo. Czy podczas tworzenia projektu wszystko zostaje podpisane własnym magazynem kluczy? Czy to duży problem? Czy to oznacza, że ​​JNLP będzie działał przyzwoicie, jeśli słoiki są podpisane certyfikatem utworzonym przez zaufany urząd certyfikacji (który nie jest bezpłatny)?

EDIT 04 czerwca 2013:

kupiłem sobie certyfikat podpisywania kodu z GlobalSign, zainstalowany na moim komputerze. Przekonwertowałem plik certyfikatu PFX do Java Key Store (JKS) i użyłem go do podpisania moich słoików (w Netbeans). Następnie zweryfikowano słoiki i wszystko wydaje się być w porządku. Jednak zaktualizowałem pliki na serwerze internetowym, uruchomiłem program za pośrednictwem pliku JNLP, ale nadal zachowuję się tak samo .. Czas na desperację!

EDIT 06 czerwca 2013:

porządku, zaczął innego podejścia.Jako test próbowałem pobrać dane XML za pomocą HTTPUrlConnection() zamiast Jersey:

Otrzymuję to samo okno "Wymagane uwierzytelnienie" podczas wykonywania żądania HTTP GET przy użyciu 7u21. Z 7u17 otrzymuję odpowiedź XML. Wciąż nikt nie ma pojęcia, co może być nie tak? Czy to może mieć coś wspólnego, ponieważ używam uwierzytelniania BASIC? Czy to może być związane z serwerem? Czy może to mieć coś wspólnego z plikiem JNLP? Im więcej odpowiedzi szukam na to pytanie, tym więcej pytań mam się wydaje :)

Answer 1

Moja odpowiedź na numer follow-up question również powinna odpowiedzieć na to pytanie.

W skrócie: Java Web Start buforuje odpowiedzi HTTP domyślnie w JDK7 i musisz ustawić nagłówek Cache-Control na "brak pamięci podręcznej, brak sklepu" na żądanie klienta i na odpowiedziach usługi Jersey REST .

Answer 2

Odpowiedź jest tutaj:

Java Web Start keeps asking to authenticate

Nie wiem, dlaczego nie doświadczyć tego zachowania przed . Być może był to problem z bezpieczeństwem w poprzednich wersjach Java Web Start lub poprzednich wersji przeglądarki.

Nie sądzę, że błąd we/wy jest związany.

Answer 3

Tego typu problemy często można rozwiązać przez Ustawienia przeglądarki:

IE -> domeny dodać do swojej listy 'intranet' terenów strefy; Chrome -> dodaj wyjątek do listy domen, w których chcesz zezwolić na wtórny dostęp przez wtyczkę.

Jeśli jesteś w zarządzanym środowisku korporacyjnym, przekaż problem swojemu personelowi ds. Bezpieczeństwa w Internecie, ponieważ tego rodzaju ustawienia są zwykle wyłączone dla plebs.

Jak wyjaśniono dla IE:

Jeśli dostęp z wtyczki są wymagane od zewnątrz „intranet” strefy, jest on automatycznie traktowane nie tyle bezpiecznie przekazać wszelkie informacje login/hasło do domeny wzywającego. Stąd wyskakujące okienko logowania, aby podać je poświadczenia od klienta. Dodanie domeny do strefy "intranetowej" rozwiąże ten problem w większości przypadków.