Фотки не грузятся.
Спер крутые строители дата-центров не смогли построить нормальный хостинг для своих же картинок.
Это же надо так вляпаться.
Что подумают потенциальные клиенты?
Это я все к тому, что сейчас сокеты как бы появились но реально использовать их нельзя. Ну по крайне мере рядовым разработчикам которые сидят на Apache+PHP. Для их реального использования нужная мощная поддержка, я бы даже сказал переделка серверной части, причем более глобальная чем клиентская.
А вообще с появлением сокетов жду «путти в браузере». Сейчас же все едет в браузер, вот и консоль можно тудаже :-)
Я предполагаю что сокеты были придуманы для того, чтобы сервер мог по собственной инициативе послать данные клиенту а не только когда его клиент попросил. Для это на сервере должно что то произойти (влететь письмо, добавится строчка в лог, сработать cron и тп) какой то другой «демон» должен попросить веб сервер кинуть такие-то данные в такой то сокет. Допустим стандартный веб сервер можно попросить об этом через http с локального адреса. Но у сервера может быть открыто например 1000 сокетов к разным клиентам, их нужно как то идентифицировать в рамках всего web сервера. Т.е. наш демон, который инициализирует событие, должен попросить веб сервер примерно так «Слышь там у тебя Вася Петя и Дима открыли сокеты, кинь в них текстом Hello world». Идентификаторы Вася Петя и Дима нужно как то получить и хранить. Мне более интересна эта практическая часть реализации. Например как через сокеты смотреть лог сервера? Что то типа tails -f в сокет. Когда в файле появляется строчка, она автоматом летит нескольким клиентам.
Я правильно понял что сервер возвращает через сокет то, что вы ему написали со странице?
Другими словами инициация плевка в сокет идет не от сервера а от клиента?
Т.е. клиент просит плюнь в меня такими то данными?
Если трафик слушается, то пароль отснифят еще когда он на сервер идет.
Если браузер или ОС заражен, то его стырят в момент ввода.
Если ни то и ни другое, то что плохого в том, что сервер вернул пароль обратно?
Где он может засветится.
Сервер отдал пароль пользователю который его и так знает.
Заглядывание из-за плеча не в счет, так можно что угодно взломать.
Работа без https это в 100 раз большая дыра чем, то что сервер возвращает пароль обратно.
В 2003 году знакомился с процессом стереолитографии (быстрого прототипирования.). Тогда за полный комплект технологии (3Д принтер + куча плюшек к нему) заплатили 2 млн у.е.
На какую ОС пишите приложения?
Не боитесь что через несколько лет поменяется сама ОС или ваше (руководства) отношения к ней?
Или завтра у вас появятся пользователи с другой ОС или с ChromeOS?
Не боитесь привязываться к одной ОС?
А в нашей компании задумались о переписывании десктопных приложений на web. При этом IE6 не включить в список подерживаемых браузеров. Т.е. если в нем не будет что то работать то и ладно…
Всеv параноикам собравшимся тут рекомендую для хранения идей KeyMemo.com
habrahabr.ru/blogs/i_am_advertising/79997/
там админ и злоумышленники ничего не могут прочитать и украсть
в поле примечание входит 4000 для идеи хватит
все шифруется
Храните идеи в KeyMemo.com habrahabr.ru/blogs/i_am_advertising/79997/
там админ и злоумышленники ничего не могут прочитать
в поле примечание входит 4000 для идеи хватит
все шифруется
А каков срок гарантированной сохранности данных? Может через 3-5 лет уже ничего нельзя прочитать?
Зачем защищать от пожара который может и не случится в течении 100 лет, если через 5 лет данные сами протухнут.
Можно термобумагу (кассовые чеки или факс) положить в сейф но это ее не спасет через год на ней ничего нельзя будет прочитать.
Для меня гораздо важнее время гарантированного хранения.
Обещали что компашки хранят записи практически вечно, и что в итоге?
Там выше один хороший человек грамотно сформулировал это так:
Стойкость последовательного применения двух алгоритмов шифрования не может быть ниже чем стойкость любого из этих двух. По-моему, это очевидно. Иначе, либо стойкость алгоритма зависит от входных данных (если мы сравниваем со стойкостью второго алгоритма), либо может быть снижена путём каких-то манипуляций с завшифрованными данными (если мы сравниваем со стойкостью первого алгоритма). Что, разумеется, противоречит самому определению стойкости.
Спер крутые строители дата-центров не смогли построить нормальный хостинг для своих же картинок.
Это же надо так вляпаться.
Что подумают потенциальные клиенты?
А вообще с появлением сокетов жду «путти в браузере». Сейчас же все едет в браузер, вот и консоль можно тудаже :-)
Другими словами инициация плевка в сокет идет не от сервера а от клиента?
Т.е. клиент просит плюнь в меня такими то данными?
Если трафик слушается, то пароль отснифят еще когда он на сервер идет.
Если браузер или ОС заражен, то его стырят в момент ввода.
Если ни то и ни другое, то что плохого в том, что сервер вернул пароль обратно?
Где он может засветится.
Сервер отдал пароль пользователю который его и так знает.
Заглядывание из-за плеча не в счет, так можно что угодно взломать.
Работа без https это в 100 раз большая дыра чем, то что сервер возвращает пароль обратно.
Тоже ожидал его увидеть.
Не боитесь что через несколько лет поменяется сама ОС или ваше (руководства) отношения к ней?
Или завтра у вас появятся пользователи с другой ОС или с ChromeOS?
Не боитесь привязываться к одной ОС?
habrahabr.ru/blogs/i_am_advertising/79997/
там админ и злоумышленники ничего не могут прочитать и украсть
в поле примечание входит 4000 для идеи хватит
все шифруется
habrahabr.ru/blogs/i_am_advertising/79997/
там админ и злоумышленники ничего не могут прочитать
в поле примечание входит 4000 для идеи хватит
все шифруется
Зачем защищать от пожара который может и не случится в течении 100 лет, если через 5 лет данные сами протухнут.
Можно термобумагу (кассовые чеки или факс) положить в сейф но это ее не спасет через год на ней ничего нельзя будет прочитать.
Для меня гораздо важнее время гарантированного хранения.
Обещали что компашки хранят записи практически вечно, и что в итоге?
Стойкость последовательного применения двух алгоритмов шифрования не может быть ниже чем стойкость любого из этих двух. По-моему, это очевидно. Иначе, либо стойкость алгоритма зависит от входных данных (если мы сравниваем со стойкостью второго алгоритма), либо может быть снижена путём каких-то манипуляций с завшифрованными данными (если мы сравниваем со стойкостью первого алгоритма). Что, разумеется, противоречит самому определению стойкости.
Все дело в том, что алгоритмы и ключи разные.
Следующий топик писать о том как пережить хаброэффект?