| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Шифрование данных с JSF |
| Автор: L0ckD0g 23.7.2010, 18:10 |
| Добрый день, можно ли в JSF (с использованием каких-либо фреймвёрков, и с небольшим гемором) реализовать шифрование данных между браузером и сервером (всех)? (при том, что активно используется ajax) поиск google 'jsf encrypt' ничего не дал кроме ssl. что-то вроде джаваскриптом перед сабмитом формы зашифровать всё, и на сервере вклиниться в цикл jsf'а, и расшифровать? если да, то куда смотреть, в какую сторону? |
| Автор: AJetman 24.7.2010, 00:45 | ||
Единственно, в форме авторизации можно использовать JS имплементацию MD5 или SHA1 для создания хэша пароля клиентом и отправки его на сервер. |
| Автор: L0ckD0g 26.7.2010, 12:50 |
| От решения HTTPs отказывается заказчик (банк), поэтому, видимо останемся на JSP :( |
| Автор: AJetman 26.7.2010, 13:44 | ||
 |
| Автор: powerOn 27.7.2010, 12:28 | ||
А почему? |
| Автор: Alexandr87 28.7.2010, 08:24 | ||
а какая собственно разница, JSP или JSF в данном случае? |
| Автор: ivanovpv 28.7.2010, 15:20 | ||
Желание заказчика закон - тем более он платит баблосы за ненужную (IMHO) разработку В таком случае я не вижу как варианте клиент (браузер) - сервер реализовать систему нормального шифрования, поскольку на стороне клиента придется что-то писать на JavaScript'е, а это очень криво - видны будут и алгоритмы и ключи. Наверное можно придумать как это обойти, но все равно очень криво. Так что остается вариант: а) с придумыванием собственного браузера (что слишком круто даже для банка  ) б) или же что более жизнеутверждающе написать что-то вроде HTTP прокси, который берет ответ клиента, шифрует и отсылает серверу, ну а сервер уже дешифрует. Для полноты картины связку клиент-прокси можно сделать на HTTPS, а связку прокси-сервер сбацать на каком-нибудь крутом алгоритме шифрования - да хоть 1024 бита. |
| Автор: mbasil 28.7.2010, 15:41 |
| Вообще ваш вопрос носит принципиальный характер. 1. Шифровать трафик надо от клиента к серверу. 2. Шифровать и расшифровывать на сервере не проблема. 3. Как Вы изволили заметить - проблема на клиенте. 4. Не понятно, чем поможет прокси, раз он в целях безопасности. должен стоять на клиенте? 5. Свой браузер - это просто приложение, работающее через HTTP протокол, которое шифрует весь трафик. Написать это не проблема. Проблема, на каком языке, для какой платформы и необходимость инсталляции. 6. То есть имеем альтернативу - либо шифровать все через TSL (HTTPS), либо писать и инсталлировать на клиенте приложение. Третьего не дано? Хотелось бы, чтобы более грамотные товарищи меня поправили. |
| Автор: cutwater 28.7.2010, 16:18 |
| По-моему третий возможный вариант - это Java-апплет. Других увы не припомню. |
| Автор: mbasil 28.7.2010, 16:24 |
| К сожалению и при использовании аплетов надо инсталлировать JVM. По долгу службы имею дело с разработчиками разных банков, и насколько я понимаю, банки в основном просят клиентов инсталлировать свои приложения. Можно использовать WebStart, но это лишь облегчает дело и не меняет ситуацию кардинально. |
| Автор: ivanovpv 28.7.2010, 17:49 | ||
Ну да так оно и есть. Может я не совсем точно выразился по поводу прокси, но я предполагал, что клиент будет продолжать работать на стандартном браузере, в настройках браузера указываем прокси который находится в локальной сети. Прокси пишем сами, он тупо принимает запросы по HTTP/HTTPS и шифрует данные и пересылает по HTTP же на удаленный сервер. Плюс только в том, что прокси находится не на клиентской станции, а где-то рядом в локальной сети (плюс в том смысле, что не надо на клиентской машине ничего инсталлировать). В общем все сильно похоже на работу какого-нить анонимайзера. |
| Автор: cutwater 28.7.2010, 23:32 |
| Осталось выяснить у ТС чем же не подошел HTTPS? |
