После обновления 7u21 появится окно с проверкой подлинности

Я работаю над проектом в течение последних 6 месяцев. Для этого проекта у меня есть экземпляр сервера Glassfish, где развертывается веб-сервис. На стороне клиента я использую JavaFX2.2, который выполняет запросы REST с Джерси (запросы/ответы XML, без JSON) с аутентификацией BASIC.

Когда пользователь запускает программу (JWS/JNLP), обычно они просто вводят свои учетные данные в собственное окно входа в систему, нажимают кнопку входа и начинают работать. Начиная с 7u21, по какой-то причине я получил дополнительное Java-сообщение "Authentication Required" (возможно, из-за измененной безопасности в 7u21).

Чтобы быть уверенным, что это не связано с проблемами совместимости между версиями Java, я также обновил сервер до 7u21, поэтому:

Клиент: обновленная версия java от 7u17 до 7u21
Сервер: обновленный java от 7u09 до 7u21, скорректированный файл asenv.bat Glassfish для использования нового jdk

Если я нажал кнопку "Отмена" в окне "Требуется проверка подлинности", показанное выше, программа действительно запускается, но при выполнении запросов она не работает стабильно:

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

Эта ошибка происходит случайным образом при использовании метода GET (не тестировалась с помощью PUT или DELETE), в этом случае это был метод 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;
}

Самое смешное, когда я запускаю программу через Netbeans или с .jar файлом, а не с .jnlp, все работает по назначению (никаких дополнительных всплывающих окон для проверки подлинности, никаких ошибок)... так что это должно быть сделано Я думаю, что-то с Java Webstart?

РЕДАКТИРОВАТЬ 28 мая 2013 года:

Я провел несколько дальнейших исследований, сравнив журналы трассировки/отладки консоли java от 7u17 и 7u21. Я заметил следующее в журнале 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

Первая строка не отображается в журнале 7u17, поэтому она должна что-то делать с подписанием баннеров? Он показывает для нескольких файлов jar то же самое. Когда вы строите проект, все подписывается с собственным сделанным хранилищем ключей, это большая проблема? Означает ли это, что JNLP будет работать только прилично, если банки будут подписаны с сертификатом, созданным доверенным ЦС (который не является свободным)?

РЕДАКТИРОВАТЬ 04 июня 2013 года:

Я купил себе сертификат подписи кода от GlobalSign, установил его на свою машину. Преобразовал файл сертификата PFX в хранилище ключей Java (JKS) и использовал тот, чтобы подписать мои банки (в Netbeans). После этого проверяли банки, и все, кажется, в порядке. Тем не менее, я обновил файлы на веб-сервере, запустил программу через JNLP файл, но по-прежнему придерживаюсь того же поведения.. Время отчаянно!

РЕДАКТИРОВАТЬ 06 июня 2013 года:

Хорошо, начал другой подход. В качестве теста я попытался извлечь XML-данные, используя HTTPUrlConnection() вместо Jersey:

Я получаю то же самое окно "Требуется проверка подлинности" при выполнении запроса HTTP GET при использовании 7u21. С 7u17 я получаю ответ XML. Еще никто не понял, что может быть не так? Может ли это что-то делать, потому что я использую аутентификацию BASIC? Может ли это быть связано с сервером? Может ли это иметь какое-то отношение к файлу JNLP? Чем больше ответов я ищу для этого вопроса, тем больше вопросов у меня есть:)

Ответ 1

Мой ответ на ваш следующий вопрос должен также ответить на этот вопрос.

Вкратце: Java Web Start кэширует HTTP-ответы по умолчанию в JDK7, и вы должны установить заголовок Cache-Control на "no-cache, no-store" в запросе вашего клиента и на ответы службы REST на Джерси.

Ответ 2

Ответ здесь:

Java Web Start продолжает запрашивать аутентификацию

Я не знаю, почему вы раньше этого не испытывали. Возможно, это была проблема безопасности в предыдущих версиях Java Web Start или предыдущих версиях вашего браузера.

Я не думаю, что ошибка ввода-вывода связана.

Ответ 3

Эти проблемы часто можно решить с помощью настроек браузера:

IE → добавить домен в свой список сайтов зоны "интранет" ; Chrome → добавить исключение в список доменов, в которых вы хотите разрешить доступ к подключению без доступа.

Если вы находитесь в управляемой среде Enterprise, перейдите к проблеме с вашим персоналом в Интернете, так как эти параметры обычно отключены для плебеев.

Как объяснено для IE:

Если доступ из плагина запрашивается из-за пределов зоны "интранет" , он автоматически считается недостаточно защищенным, чтобы передавать информацию о пользователе или пароле в запрашивающий домен. Следовательно, вход для входа в систему, чтобы предоставить ему учетные данные от клиента. Добавление домена в зону "интранет" в большинстве случаев позволит решить эту проблему.