13.14 Ограничения скриптов

По соображениям безопасности, скрипты имеют множество ограничений, и есть много вещей, которые они просто не могут делать. Обычно возникают вопросы о том, что скрипты могут сделать, а также слухи о том, какие возможности они предоставляют: расширение функциональности веб-страниц в браузере. Как пользователи интернета, мы никогда особенно не задумывались над тем, приходит ли веб-страница от добросовестного или недобросовестного источника; нам нужна была возможность безопасно выполнять код. Поэтому мы можем заметить большое количество ограничений:

(1) Скрипт не может получить доступ к локальному диску. Это означает, что он не может читать или записывать данные на локальном диске. Мы не хотим, чтобы скрипт мог через веб-страницу получать и передавать важную информацию. Запись запрещена, конечно же, поскольку это может привести к распространению вирусов. Когда цифровая подпись действует, эти ограничения снимаются.((2)) Скрипт не может иметь меню. (Примечание: это правило применяется в Swing.) Это может уменьшить проблемы безопасности и упрощения программы. Мы можем получить уведомление о согласованной выгоде скрипта как части веб-страницы; обычно мы не обращаем внимания на область действия скрипта. Здесь нет рамок и панелей заголовков, выдвигающихся из меню; рамки и панели заголовков принадлежат веб-браузеру. Возможно, дизайн будет изменён в будущем так, чтобы позволить объединять меню браузера и меню скрипта — влияние скрипта на его окружение может слишком сильно навредить безопасности всей системы и усложнить работу с ним.(3) Диалоговые окна не доверяются. В Java диалоговые окна имеют некоторые проблемы. Во-первых, они не могут корректно отфильтровать скрипты, что весьма печально. Если мы вызываем диалоговое окно из скрипта, мы видим сообщение "недоверенный скрипт" на самом диалоговом окне. Это потому, что теоретически возможно обмануть пользователя, заставив его думать, что он работает с локальным приложением известного ему клиента через веб и вводит свои данные кредитной карты. После просмотра графического интерфейса, созданного AWT, мы можем горько констатировать, что любой человек может быть обманут таким образом. Однако скрипт всегда связан с одной веб-страницей и виден в браузере, тогда как диалоговые окна не имеют такой связи, поэтому теоретически это возможно. Таким образом, мы редко встречаем скрипты, использующие диалоговые окна.

В более новых браузерах многие ограничения для доверенных скриптов были сняты (доверенные скрипты проверены источником доверия). При разработке апплетов следует учитывать следующие вопросы:+ Апплеты постоянно скачиваются с одного сервера, который обслуживает различные классы. Наш браузер может кэшировать апплеты, но это не гарантируется. В Java 1.1 была введена возможность использования JAR (Java ARchive) файлов, что позволяет объединять все компоненты апплета (включая другие классы, изображения, звуки) в один архивируемый файл, который может быть обработан одним сервером для загрузки. "Цифровая подпись" (которая проверяет создателя класса) может быть эффективно добавлена к каждому отдельному JAR файлу.

• Из-за проблем безопасности некоторые задачи становятся более сложными, например доступ к базам данных и отправка электронной почты. Кроме того, ограничения безопасности делают доступ к нескольким хостам очень трудным, так как всё должно проходить через веб-сервер, что создаёт производственные бутылочные горлышки, и любое сбой в одном этапе приведёт к полной остановке процесса.
• Апплеты в браузере не имеют таких же типов контроля, как локальные приложения. Например, поскольку пользователи могут закрывать страницы, апплеты не имеют возможности использовать диалоговые окна. Когда пользователь изменяет веб-страницу или выходит из браузера, это становится настоящей катастрофой для наших апплетов — нет способа сохранить состояние, поэтому информация будет потеряна во время обработки и операций.К тому же, когда мы покидаем веб-страницу, различные браузеры будут выполнять различные действия с нашими апплетами, поэтому результат всегда непредсказуем.## 13.14.1 Преимущества апплетов

В данном случае текст уже переведён на русский язык, поэтому нет необходимости вносить изменения.Если можно принять эти ограничения, то некоторые преимущества апплетов также весьма значительны, особенно при разработке клиент/серверных приложений или других сетевых приложений:

• Вопросы установки отсутствуют. Программные сегменты обладают истинной платформенной независимостью (включая возможность легко воспроизводить звуковые файлы), поэтому нам не требуется модифицировать код для различных платформ или требовать от пользователей выполнения каких-либо "настроек" при установке. На самом деле, установка автоматически связывает веб-страницу с программным сегментом каждый раз, обеспечивая тихое и автоматическое обновление. В традиционных клиента/серверных системах установка нового версии клиентского программного обеспечения является настоящим кошмаром.

• Из-за вопросов безопасности, созданных в основе Java-языка и структуре программных сегментов, мы не беспокоимся о том, что плохой код может повредить систему пользователя. Таким образом, вместе с вышеупомянутыми преимуществами, можно использовать Java (как альтернативу JavaScript и VBScript для клиентской веб-разработки) для создания приложений для так называемых Intranet (внутренних корпоративных сетей, используемых внутри компании, но не передающихся через Интернет).+ Поскольку программные сегменты автоматически интегрируются с HTML, у нас есть встроенная независимая файловая система платформы для поддержки этих сегментов. Это интересный подход, поскольку мы привыкли иметь часть файловой системы в виде программных файлов, а не наоборот.