асинхронная загрузка javascript из / WEB-INF / с использованием сервлета: общая проблема - PullRequest
Новая
       8

асинхронная загрузка javascript из / WEB-INF / с использованием сервлета: общая проблема

0 голосов
/ 16 февраля 2012

Я загружаю файлы javascript асинхронно в моем веб-приложении Java EE с помощью сервлета.

Файлы js помещаются в папку / WEB-INF / js / .

Ход процесса выглядит следующим образом:

in index.jsp : 

<script src="/servlet/mainLoader.js">

сервлет выполняет необходимую работу для получения файла js изнутри / WEB-INF / js / .

В общем, я называю один основной js файл mainLoader.js , который сам загружает остальные файлы js в мое приложение. Причиной этой архитектуры является скрытие некоторой важной информации в файлах js , чтобы пользователи не могли просматривать путь к файлу и проверять исходный код.

У меня два вопроса:
- Это считается плохой практикой?
- В настоящее время я занимаюсь разработкой своего приложения локально (localhost) . Будет ли эта js система загрузки вызывать проблемы при переходе в рабочий режим? я имею в виду, сможет ли удаленный пользователь загрузить файлы js, не находясь на локальном хосте?

ОТВЕТ:
@ BalusC заставил меня понять, где была ошибка в моем выборе. Я не осознавал, что такого рода JS-выборка работает только с GET-запросом. Я думал, что это будет работать с POST и, таким образом, отключить метод GET на сервлете (чтобы к JS нельзя было получить доступ непосредственно из панели URL).

Кроме того, то, что сказал @ David , верно, однако я пытался сделать не очень простым чтение источника JS.

Итак, я обнаружил, что @ Тодд Чаффи абсолютно прав, извлеченный урок:
"1) Безопасность через неизвестность - это задокументированная плохая практика."

Ответы [ 3 ]

3 голосов
/ 16 февраля 2012

Вы не можете скрыть код JavaScript от пользователя. Даже если вы добавите дополнительный код с помощью тега скрипта, пользователь сможет получить код с помощью таких инструментов, как firebug.

Если вы хотите защитить код, вы должны взглянуть на «минификаторы» и «обфускацию кода». Тем не менее, это не защитит конфиденциальные данные, такие как пароли и т. Д.

2 голосов
/ 16 февраля 2012

Ответы на оба вопроса:

1) Безопасность из-за неясности является документированной плохой практикой.

http://en.wikipedia.org/wiki/Security_through_obscurity

2) Удаленные пользователи должны быть в состоянии загрузить любой файл JS, который использует браузер.Так что они обязательно получат доступ к вашим скриптам.Я не вижу проблемы со сценариями, живущими в локальной файловой системе и перемещающимися с локального хоста в рабочий, но почему бы просто не протестировать это?

1 голос
/ 17 февраля 2012

По первоначальному вопросу:

- Это считается плохой практикой?

Это не обязательно плохая практика.Это просто не имеет смысла.Зачем брать на себя работу встроенного сервлета по умолчанию для сервлетконтейнера?

- В настоящее время я занимаюсь разработкой своего приложения локально (localhost), не вызовет ли эта система загрузки js проблемы при переходе в рабочий режим?Я имею в виду, сможет ли удаленный пользователь загрузить файлы js, не находясь на локальном хосте?

Это означает, что вы думаете, что код Java работает в веб-браузере (на стороне клиента).Это предположение неверно.Java-код работает на веб-сервере (на стороне сервера).Это будет работать одинаково хорошо, пока вы не измените относительные URL.

Согласно комментариям:

что я не понялявляется то, что этот вид JS выборки в настоящее время работает только с GET-запросом.Поскольку он не работает с POST (что я и собирался сделать), то да, пользователь может получить доступ к JS через строку URL.

POST абсолютно не более "безопасен"чем получить как "человек в середине" атаки.POST предназначен только для неидемпотентных запросов, а GET - для идемпотентных запросов.Единственный способ предотвратить ваши HTTP-запросы от атак «человек посередине» - использовать вместо этого HTTPS.

...