Pull to refresh

Comments 122

chrome 6.0.422
После нажатия на кнопку Create WebSocket пишет WebSocket closed, а в консоли ошибка — Error during WebSocket handshake: 'sec-websocket-origin' header is missing
Совершенно непонятно как это может повысить безопасность.
Эти меры направлены на то, чтобы исключить подделку веб сокетных запросов с помощью ajax. Здесь уже на этапе установления соединения такой запрос должен быть отбракован сервером.
Тогда уж проще было тупо добавить «bullshit» в тело GET-запроса. Зачем все эти ключи и подтверждения… тут дело явно в другом.
UFO landed and left these words here
UFO landed and left these words here
Дело в том, что в новой редакции спецификации (ревизия 76) введен усиленный режим безопасности для предотвращения подделки запросов. Теперь новые версии браузера не принимают запросы, сделанные по старой версии протокола (ревизия 75).

Я на днях писал про это в твиттере:

twitter.com/lisitsky/status/15331679113:
starting from #WebKit nightly build r59903 and #Chrome 6.0.414.0 (r47952) can't work with #websockets ver-75 only ver-76. upgrade servers.


twitter.com/lisitsky/status/15331373734:
bit.ly/d62Rf6 #chromium updated #websockets implementation to version 76 (details — bit.ly/cvDaLl) #chrome
UFO landed and left these words here
1. Javascript казалось бы тоже ;-)
2. Извините, но мне показалось что это даже близко не тянет на аналог.
3. Возможно я скажу банальность, но fork() это функция уровня ядра операционной системы, и PHP никаким боком не влияет на него. Если у вас процессы работают на одном ядре, когда другие ядра idle, копайте в сторону ядра.
3. Тут я думаю дело в POSIX-интерфейсе. Вы ведь знаете, что у Микрософта функция создания нового процесса принимает 7 аргументов, два из которых структуры по как минимум 6 полей. Так что копать вряд ли есть куда. Вокруг камень.
Тут timmy говорит о PHP под Windows, как я понимаю?
UFO landed and left these words here
Открыл в IE и Opera — не работает. Слив засчитан.
Проверь, у тебя походу порты закрыты.
Потому что у меня все работает во всех браузерах.
Line: 310
Error: You are trying to call recursively into the Flash Player which is not allowed. In most cases the Javascript setTimeout function, can be used as a workaround.
Очень странно.
Какие браузер и система?
Какие плагины стоят? Флешблок, адблок и другие?
Стоит flash и silverlight. Это я проверял браузер-который-нельзя-называть, версия 8, 32бит
Да, операционная система — единственная им поддерживаемая. версия 2008R2
Будущее давно здесь. Но не в РНР, а в Эрланге :)
Люто-бешено плюсую! :)
И скромно добавляю, что у меня вариант как раз на Эрланге :)
Правда там сейчас довольно старая версия — на июнь запланирована новая.
Кстати, весьма полезное улучшение.
Грамотный и удобный fall-back для тухлых клиентов — очень полезная вещь на «переходный период», пока еще не все браузеры имеют нативную поддержку Web Sockets, и еще не все админы корпоративных сетей научились настраивать под них прокси-сервер.
посмотрел демку, а в какой момент сервер дергает клиента…
судя из листинга, если не копать, за sendFrame может быть и обычное echo.
я к тому, что не совсем удачный пример.
Возможно, но это лишь пример. Ведь отправка и прием друг от друга не зависят, соответственно сервер шлет пакет в любой момент, и то что он во времени близок к моменту отправки пакета клиентом на сервер — никак не влияет на суть.
> судя из листинга, если не копать, за sendFrame может быть и обычное echo.
Суть в том что 'pong' идет не ответом на 'pong', а в ответ на другой запрос (poll).
замечательно!

зы: может стоит добавить в теги «js»?
а смысл серверной части, если прозрачной должна быть работа с клиентской?
UFO landed and left these words here
а кроме чатов и игр где это еще может использоваться?
Хороший вопрос. Навскидку:
— Коллаборативные приложения когда несколько человек одновременно редактируют один и тот же документ, там важно получать непрерывный поток изменений с минимальной задержкой.
— Уведомления о чем бы то ни было.
— Отображение данных в системах мониторинга.
а между двумя клиентскими частями можно открыть веб-сокет, чтобы организовать видеосвязь без сервера?
Теоретически можно, флеш умеет биндить порт. Только непонятно зачем там вебсокет =) Это же надстройка над HTTP, а зачем двум клиентам HTTP? Это всё равно что целоваться через полиэтиленовый пакет.
Про Server Events забыли, которые в «Опере» есть.
Это long polling только сбоку. Более удобный.
Не обижайтесь, но мое лично мнение Server Sent Events — это ненужный шлак.
Это как бы улучшенный стриминг, имеющий все проблемы обычного стриминга.
Кроме того, реализация в опере неправильная — тег по стандарту должен называться по-другому dev.w3.org/html5/eventsource/
А мне-то чего обижаться? Я к «Опере» отношения не имею. По замечаниям:
1) если это входит в стандарт, это всё равно придётся реализовать
2) когда в «Опере» реализовывали, то стандарт был другим.
1) мне кажется, что этот стандарт умрет. Т.к. это полумеры. Сейчас есть веб сокеты — технология на порядок превосходящая SSE.
2) Оперщики поспешили. Начали делать, когда еще ничего не было известно.
1) Может и умрёт, может и нет. Он простенький, в некоторых случаях его хватает.
2) Все спешат. HTML5 не принят, CSS3 — тоже. Ещё многое может поменяться. Вот в SSE уже поменялось, в VIDEO ещё не пришли к тому какой будет кодак, а все уже навтыкали поддержку в браузер. Даже border-raduis и тени везде по-разному работают.
Кажущаяся вам непомерной сложность лонг поллинга проистекает из отсутствия в PHP родных примитивов синхронизации и конструкций контроля конкурентности помимо C-шных. Именно поэтому невозможно реализовать на PHP такую штуку, как например продолжения, которые позволяют абстрагироваться от long-polling'a жить в прекрасном мире без костылей и ужасов.

Предупреждая комментарии по поводу того, что это можно сделать написав горы C-стайл кода, скажу, что использование процессов уровня ядра для таких мелких взаимодействий, как отправка и приём небольших порций данных, как минимум неэффективно, а написание собственного планировщика потоков на PHP как минимум глупо.
например какой то forex отдает какую то статистику только для своего домена, что будет мне мешать получать эту статистику?
За 5 мин напишу промежуточный модуль который будет получать эти данные подменяя Origin, и после получения данных выводить информацию непосредственно уже на свой сайт.

Клиент -> Мой сервер -> подмена Origin -> forex
forex -> Мой сервер -> Клиент

Как избежать этого?
Что значит только для своего домена? На странице стоит какая-то ajax обновлялка, которая подгружает данные с сервера?
В таком случае вы можете уже сейчас тырить с нее данные :)
Просто закачиваетет данные CURL- ом и все. Потому что ограничение на домен проверяется браузером.
Обрабатывая заголовок Origin: сервер будет решать отдавать контент или нет.
Вопрос состоит в том как мне защитить данные.
Я хочу отдавать контент с сервера только тем клиентам которые находятся на моем сайте.
Клиенты сидят дома с чашкой кохва в руке, а не находятся у вас на сайте ;-) Никак.
хм, нужно будет добавит еще один заголовок, какой то хеш, который будет генерироваться javascript'ом при заходе на сайт и передаваться
на сервер. И в момент генерации куда то сохранять на сервере. И когда происходить соединение с web-socket сравнивать совпадение.
ключ будет генерироваться с помощью javascript + python.
Например когда клиент заходит на страничку, python генерирует контент в котором будет что то
на подобии
document.write(unescape('%3C%73E%65%73%63%61%70%65%28%74%29%29%3B%7D%3C%2F%73%63%72%69%70%74%3E'));dF('%264DTDSJQU%2631MBOHVBHF%264E%2633kbwbtdsjqu%2633%264F%261B00%2631TBNQMF%2631TDSJQU%2631%26342%261Bwbs%2631ibtilfz%264E%2631%2638btebtebebebebebe%2638%264C%261B%264D0TDSJQU%264F1')
где спрятан ключ.
Javascript в данном примере играет роль шифрования ключа и определения что именно браузер зашол на сайт, а не самописный скрипт, как это сделать вариантов много.
Ключ генерируется на сервере с помощью python или другого языка.
Для каждого клиента свой ключ, с этим ключом можно создать только одно tcp соединение. Если соединение прервано
ключ уже не валидный.
Стоп… стоп… стоп…
Вы замечательно расписали техническую часть. Но, по-моему, мы ушли от первоначальной задачи. Давайте ее сейчас четко сформулируем.
Если ваши данные на сайте публично доступны, то всегда можно написать скрипт или проксик, который их заберет. Пример — любой поисковик в интернете, кеширующий страницы.
Давайте проясним задачу.
Вам нужно сделать на сайте некий информер, который с помощью веб сокетов будет получать данные с сервера и показывать их пользователю. При этом вы не хотите, чтобы этот информер можно было легко скопировать на другую веб-страницу где бы он показывал то же самое. Верно?
Вопрос: ваши данные публично доступны? Они отдаются всем пользователям вашего сайта или только определенным?
Верно я не хочу чтобы кто попало мог у себя на сайте создать web-socket и конектится к моему серверу.
Что касается публичности, неважно, пусть грабит хоть весь сайт.
ну тогда только как вы уже и сказали. Добавлять в заголовок какое-то поле с «секретным» хэшем
Это как раз ничего не даст — потому что тот самый заголовок точно так же можно вставить. Алгоритм шифрования и ключи не помогут — т.к. если это делает на стороне клиента, то вскрыть их не проблема.
Нужно использовать возможности протокола для ограничения. Это намного проще и надежнее.
чтобы его вставить вам нужно его узнать + он уникален для каждой сессии. Второй раз уже не используешь.
Похоже, мы с вами по-разному представляем этот механизм — распишите его подробно.
да все как обычно, после аутентификации клиента посредством обычного запроса сервер генерирует уникальных ключ который обязан присутсвовать в загаловках запроса.
Понятно что если мою сеть «слушают» то мало что спасет.
> после аутентификации
то есть клиент должен аутентифицироваться?
не подходит по условию задачи — сервис должет быть публично доступен с нужного сайта
ну тогда я пас :) без этого любой будет иметь доступ.
алгоритм работает на стороне сервера, на стороне клиента нету алгоритма.
Вы для себя подробно распишите схему работы.
> Javascript в данном примере играет роль шифрования ключа и определения что именно браузер зашол на сайт, а не самописный скрипт, как это сделать вариантов много.

подделывается на стороне клиента, потому что алгоритм открыт и все данные открыты.
ключ делается на сервере, java лишь его маскирует и определяет что именно браузер зашел на сайт а не скрипт.
ну а что тогда мешает злоумышленнику также маскироваться с помощью скрипта?
ничего не мешает, вопрос в том как вы получите ключ?
а как вы? Если по какому то секретному каналу то тогда это ничем практически не отличается от обычной аутентификации, а если публичным обарзом — я его также получу.
Ключ вы получите если зайдете только браузером, а не скриптом на мой сайт.
так скрипт то будет полностью подделываться под браузер. Со всеми заголовками и прочим.
это уже мелочи, вариантов как отличить скрипт от браузера много. Что касается остального то вам придется писать новый браузер.
> вариантов как отличить скрипт от браузера много
хоть 1 надежный
1.проверка может ли ваш скрипт обрабатывать javascript
поддерживает ли ваш скрипт css,audio,video,…
Выпейте яду. А потом откройте для себя программирование с webkit.
выпил, пишите свой новый браузер, с поддержкой
css, audio,video,forms,… а потом подумаете стоило
его начинать.
Зачем писать новый броузер? Чтобы не вникая в суть вашего javascript-кода заставить программу «зайти на сайт», «нажать кнопку» и получить нужные данные не нужно писать новый броузер. Достаточно написать простенький скрипт на основе webkit.
не вопрос, но перед тем как вам отдать ключ, javascript будет делать проверку на поддержку вашим скриптом css, audio,video,forms и всех других
технологий корыте поддерживаются настоящими браузерами их десятки. Необязательно проверку всех, рандомно одну или две.
а как сервер будет узнавать что поддерживаю? Только получением каких то пактов данных. Что мне мешает на все проверки всегда отдавать ответы TRUE ну или какую там сигнатуру вы ждете в случае если проверка прошла?
А здесь и вся соль, чтобы узнать нужно будет тратить свое время, чтобы понять как все работает.
Система станет уязвима если вы зделаете полноценный эмулятор браузера, это означает что вы должны будете выполнить все сценарии которые вам отдаст сервер при первом заходе. На сервере я смогу регистрировать что вам было отдано.
И потом парсить постоянно сайт это не выход, так как можно бесконечно долго менять содержимое странички, меня все компоненты.
да не надо ничего парсить. Я один раз посмторю что отдает назад на сервер ваш клиентский сценарий и буду отдавать тоже самое. Даже если вы будете использовать какое-то локальное шифрование с переменным ключом я тупо скопирую этот код из вашего скрипта — исходники его у меня все равно есть.
если не отдавать как тогда сервер узнает что проверка прошла успешно и этому клиенту можно передавать данные?
а это вам никто не скажет, вам придется сделать полноценный браузер, мало ли я там напридумывал.
вы для начала придумайте как вы будете своему серверу «говорить» что валидация прошла успешно. А уж потом мне.
При заходе на страничку запускается python скрипт который генерит ключ и передает на страничку и копию хранит у себя. При условии что вы зашли браузером или эмулятором только тогда на страничке будет ключ.
Когда вы инициализируете web-sock соединение передается на сервер этот ключ.
Как определить что вы именно зашли браузером вариантов много, но их все можно подделать. Поэтому каждый раз будет новая проверка. Вам придется каждый раз ее искать.
я веду к тому что не только с помощью javascript можно определить скрипт зашел на сервер или браузер. Есть еще десятки других способов.
Если больше подумать то их и сотни можно найти.
А парсить придется так как ключ генерируется моим сервером, да и можно время жизни ему поставить.
расскажите хотя бы еще один способ из десятка который я не смогу подделать?
Вы так и не поняли идеи.
Вы сможете подделать все мои способы.
Я могу их периодично менять, их будет бесконечное число.
Вам придется по новой анализировать код.
Проще написать полноценный эмулятор, а это уже ничем не будет отличатся от баузера.
любая ваша технология всегда будет упираться в проблему «бутылочного горлышка» в виде посылки запросов к серверу, которые у меня как на ладони.
серверу посылается только один запрос это ключ, который вам предоставляется при заходе на страничку. Но этот ключ ничего не стоит если вы не прошли проверку на валидность браузера. Этот ключ и есть разрешением на открытие web-socket
Например валидность браузера можно определить выполнение какого то javascrit, а можно и по другому, каждый раз проверка будет меняется, и вы будете каждый раз ее искать и тратить время на анализирование сайта, что сведет на нет всю идею. Вам попросту придется написать свой браузер.
валидация все равно происходит на клиенте, значит мне доступен ее алгоритм. В самом крайнем случае если вы будете менять ее шибко часто, ну тогда нужно будет плагин к браузеру, это максимум.
она будет меняться каждый раз когда вы зайдете на страничку.

Ну а как браузер прикрутить к apache серверу?
Ведь идея стоит в том чтобы скрипт п*здил контент с чужого сайта по методу web-socket.
Клиент заходит на А сайт устанавливается web-socket соединение с этим же А сервером. А сервер п*здит контен с В сервера. По вашему нужно на А сервер
поставить браузер с плагином и прикрутить его каким то образом к apache. Я это мало представляю.

В данной дискусии я вижу только один выход написания скрипта эмулятора который будет заменять браузер.
Или же переписывание исходников какого то свободного браузера чтобы можно его было прикрутить к вебсерверу.
то есть проверка делается на стороне клиента?
клиент шлет ключ на сервер в дополнительном заголовке, на сервере этот ключ проверяется валидный ли он.
Выше я уже написал как оно должно работать.
так кто генерирует ключ?
Если сервер, то я зайду своим скриптом и получу его.
Если клиент — я просто посмотрю как он его генерирует и буду делать тоже самое.
выше я описал схему.
Ключ сгенерил сервер, вы его получите, если вы
зашли браузером на сайт и только им, отличить браузер от скрипта элементарно, вариантом миллион.
Ключ будет уникальным для каждого клиента, и время жизни его только на одну сессию, тобиш при повтором обновлении странички или закрытии web-socketa ключь уже не валидный
могу вас заверить что мой скрипт не будет никак отличаться от браузера. В конце-концов это может быть чутка подправленный браузер. Начиная от помощи плагинов, заканчивая правкой исходников и т. п.
и вы забыли что его еще нужно прикрутить к веб-серверу.
Чтобы работала схема.
Клиент -> Мой сервер -> подмена Origin -> forex
Где «подмена Origin» вам нужно умудриться прикрутить свой браузер с плагинами.
Настоящий браузер будет проблематично туда прикрутить, что касается скрипта который будет эмулировать работу браузера, это и есть полноценный браузер, если у вас такой есть поделитесь.
Эта проблема уже решена в протоколе :)
Как раз для проверки откуда идет подключение сделан заголовок Origin. Когда вы его получаете, просто проверьте, что подключение идет с вашего домена. Если нет, то имеете право сбросить подключение.
Либо же выдать свой Origin — если они не совпадут, браузер сам должен закрыть подключение.
Origin всегда одинаковый. Любой сможет воспользоваться.
Вы уверены?
Расскажете как именно это можно сделать?
Кончайте флудить =) У человека в голове каша, и ее так просто не удалить.
Заголовок Origin отсылает браузер клиента, и в нем передается URL с которого была вызвана сессия web-sock.
Именно на браузер будет возложена задача чтобы этот заголовок был правильным. Но мне ничего не мешает его подменить, написать скрипт и слать
любой Origin
ЯваСкриптом? напишете такой?
сервер я предоставлю.
Мой самый первый пост
Клиент -> Мой сервер -> подмена Origin -> forex
причем здесь javascript?
В данной схеме я буду п*здить контент с forex
и показывать на своем сайте, п*здить я его буду с помощью скрипта на писаного на любом языке (python, php,///)
В данной схеме мой сервер будет выступать в качестве посредника.
ну я уже описал как я сделал это в моем сервере, но это действительно ничего нового, просто обычная авторизация, никакой публичности.
Кто мешает аутентифицировать коннект?
Например, так сделано у меня в чате. Вначале клиент подключается и начинает получать события из чата: изменение списка пользователей, новые сообщения и так далее.

Если он хочет писать, то ему надо авторизоваться на сервере. Для этого он отправляет специальный запрос, сервер его проверяет и назначает данному коннекту данного пользователя. Можно сделать проверку по спец. ключику, логину/паролю и так далее.

Так же, поскольку мы знаем, какое подключение какому клиенту принадлежит, то мы можем контролировать их количество — например не позволять подключаться повторно, пока работает текущее соединение. Кроме того, при необходимости можно очень легко отключить клиента — просто сбросив его соединение.
Только авторизация.
Все остальное забирается элементарно.
Only those users with full accounts are able to leave comments. Log in, please.