Сокет-соединение с исходным сервером неподписанного Java-апплета - PullRequest
2 голосов
/ 12 мая 2009

Я везде читал, что неподписанным Java-апплетам не разрешается устанавливать сетевые подключения ни к одному серверу, кроме того, на котором был создан апплет. Это нормально для моего приложения, так как мой апплет должен только общаться с сервером. Однако когда я написал тестовый апплет, чтобы попытаться открыть сокет для связи с процессом на моей машине разработки, он выдает следующее исключение:

Error establishing socket connection:
java.security.AccessControlException: 
  access denied (java.net.SocketPermission 127.0.0.1:11000 connect,resolve)

Код, вызвавший исключение:

private void sendMsg(String msg) {
   Socket s = null;
   try {
      s = new Socket("localhost", 11000);
   }
   catch (Exception e) {
      System.err.println("Error establishing socket connection:");
      e.printStackTrace();
      return;
   }

   try {
      OutputStream out = s.getOutputStream();
      out.write(msg.getBytes());
      out.flush();
      s.shutdownOutput();
      s.close();
   }
   catch (Exception e) {
      System.err.println("Error in writing to the socket:");
      e.printStackTrace();
   }

Сначала я подумал, что в моем коде есть проблема, из-за которой моя неопытность заставила меня пропустить. Однако я получаю то же исключение при попытке запустить пример Talk Server из официальных учебников по Java. Это заставляет меня поверить, что у меня действительно есть проблема с настройкой или неправильное понимание ограничений безопасности по умолчанию. Предотвращает ли менеджер безопасности по умолчанию открытие сокетов на машине, на которой запущен апплет, даже если это также машина, обслуживающая апплет? Если это так, то это проблема для меня, потому что развернутая система должна позволять пользователю, вошедшему в систему на фактическом сервере, использовать тот же апплет, что и удаленный пользователь. Есть ли способ обойти исключение, которое я получаю, которое не включает в себя подписание апплета? Я не хочу идти на неприятности, если в этом нет необходимости.

ПРИМЕЧАНИЕ: Я знаю, что было бы лучше, чтобы пользователи не обращались к апплету с сервера. Это был не оригинальный дизайн, но, к сожалению, практические соображения вынудили меня пойти на компромисс.

ОБНОВЛЕНИЕ: Просмотр страницы апплета с веб-сервера решает проблему. Даже если сервер является локальным. Обновление безопасности в Java 1.6.0_11 применяется только к апплетам, загружаемым непосредственно из локальной файловой системы.

Ответы [ 3 ]

4 голосов
/ 12 мая 2009

Это связано с изменением плагина, введенного в недавнем обновлении безопасности. Сожалею! Апплетам, загруженным из локальной файловой системы, больше не предоставляются разрешения сокетов для localhost.

Решение 246387: Уязвимость безопасности в среде выполнения Java может позволить коду, загруженному из локальной файловой системы, обращаться к LocalHost

Среда выполнения Java (JRE) позволяет загружать код с локального файловая система для доступа к localhost. это может разрешить злонамеренный код размещены на локальной файловой системе и затем запустить, чтобы иметь сеть доступ к localhost, который не будет в противном случае будет разрешено, если код загружается с удаленного хоста. Это может быть использовать для кражи печенья и угона сеансы (для доменов, отображающих имя на локальный хост).

2 голосов
/ 12 мая 2009

Я подозреваю, что вы запускаете апплет из локального HTML-файла (например, applet.html), что вызывает ошибку, о которой упоминает Том Хоутин.

Вместо этого запустите веб-сервер (например, Tomcat ) на своем компьютере и получите доступ к файлу через <a href="http://localhost/applet.html" rel="nofollow noreferrer">http://localhost/applet.html</a>

Вероятно, было бы лучше открыть порт сокета из сервлета в вашем веб-сервере. Таким образом, ваш веб-сервер управляет всей вашей системой, и это может быть проще для переноса между компьютерами.

Я регулярно использую одну и ту же настройку с сокетным соединением между апплетом и сервлетом как на локальном, так и на живом.

1 голос
/ 22 ноября 2010

Oracle знает об этой проблеме Java, которая строго ограничивает использование апплетов: уязвимость безопасности в среде выполнения Java может позволить коду, загруженному из локальной файловой системы, получить доступ к LocalHost, о чем они говорят. Это был Bug Id 6704154

И их решение таково: для этой проблемы нет обходного пути; этот «обходной путь» был выпущен 3 декабря 2008 года. Итак, если вы хотите использовать Applets с Tomcat или любым другим подобным сервером, вам придется вернуться к Java 1.4.2

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...