Действительно ли прокси-сервер может кэшироваться, SSL ДОБИРАЕТСЯ? В противном случае действительно ли ответ придал бы форму шифрование, достаточны?
Ну, вы могли бы вы Javascript.
$(document).ready(function() { // or on.load()
alert("Hellow World");
});
Или
Вы можете создать класс в Python в вашем views.py, назвать его, скажем, Robot, а затем создать функцию с именем messages и записать целую кучу из них в переменные. затем передайте их в свой контекстный словарь. Используйте Django шаблонные теги с условными выражениями для отображения сообщений, когда вы этого хотите.
Javascript - это еще один отличный вариант, вы можете создать message function, который вы можете обновить после определенного предложения.
6 ответов
Нет, не возможно кэшировать https непосредственно. Целая коммуникация между клиентом и сервером шифруется. Прокси находится между сервером и клиентом для кэширования его, необходимо смочь считать его, т.е. дешифровать шифрование.
можно сделать что-то для кэширования его. Вы в основном делаете SSL на своем прокси, прерывая SSL, отправленный клиенту. В основном данные шифруются между клиентом и Вашим прокси, они дешифрованы, читайте и кэшируемый, и данные шифруются и отправляются на сервере. Ответ с сервера аналогично descrypted, читайте и зашифрованный. Я не уверен, как Вы делаете это на главном программном обеспечении прокси (как сквид), но это возможно.
единственная проблема с этим подходом состоит в том, что прокси должен будет использовать сам подписанный сертификат для шифрования его клиенту. Клиент сможет сказать, что прокси в середине считал данные, так как сертификат не будет от исходного сайта.
Выезд www.bluecoat.com является коммерческим прокси, что на самом деле CAN делают https перехват, чтобы заблокировать сайты, ограничить содержание, осматривает для вирусов, и содержимое кэша (ДОБИРАЕТСЯ)
Я думаю, что необходимо просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая делает кэширование (Исключая: WinInet на окнах). Трудно предположить, что преимущества предприятия широкое кэширование стоят боли записи пользовательской забавы схемы шифрования или сертификата безопасности на прокси. Хуже, на схеме шифрования Вы упоминаете, выполнение асимметричных шифров на теле объекта кажется, что огромный перфект совершил нападки на стороне сервера Вашего приложения; существует причина, что SSL использует симметричные шифры для фактической полезной нагрузки соединения.
я думаю, что необходимо просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая делает кэширование (Исключая: WinInet на окнах). Трудно предположить, что преимущества предприятия широкое кэширование стоят боли записи пользовательской забавы схемы шифрования или сертификата безопасности на прокси. Хуже, на схеме шифрования Вы упоминаете, делание asynmetric шифры на теле объекта кажется, что огромный перфект совершил нападки на стороне сервера Вашего приложения; существует причина, что SSL использует симметричные шифры для фактической полезной нагрузки соединения.
затронутое приложение не является приложением браузера, это - настольное приложение, вытягивающее данные по Интернету. То, что собирается произойти, - то, что все экземпляры приложения будут вытягивать ту же часть приблизительно в в то же время. Эти данные должны быть защищены, но я надеюсь увеличиться, перфект при наличии некоторых экземпляров приложения получают кэшированную версию от корпоративного прокси-сервера.
блоки данных являются маленькими, но их можно часто требовать. По существу все экземпляры приложения собираются запросить те же данные друг как друг одновременно.
данные/тело сообщения по стороне сервера будут предварительно шифроваться и кэшироваться в распределенной хеш-таблице в оперативной памяти. Шифрование не будет выполнено на основе на запрос.
я также исследую использование шины сообщения, такой как NServiceBus вместо этого.
Комментарий Rory, что прокси должен был бы использовать самоподписанный сертификат если не stricltly верный.
прокси мог быть реализован для генерации нового сертификата для каждого нового хоста SSL, с которым просят иметь дело и подписать его с общим корневым сертификатом В сценарии OP corportate среды, общий сертификат подписания может скорее легко быть установлен как доверяемый CA на клиентских машинах, и они с удовольствием признают, что они "фальсифицировали" сертификаты SSL для трафика, проксируемого, поскольку не будет никакого несоответствия имени хоста.
На самом деле это точно, как программное обеспечение такой как Charles Web Debugging Proxy допускает контроль трафика SSL, не вызывая ошибки безопасности в браузере, и т.д.
Как насчет настройки серверного кэша на сервере приложений за компонентом, который шифрует ответы https? Это может быть полезно, если у вас настроен обратный прокси.
Я думаю о чем-то вроде этого:
application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)