Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
chrome 6.0.422
После нажатия на кнопку Create WebSocket пишет WebSocket closed, а в консоли ошибка — Error during WebSocket handshake: 'sec-websocket-origin' header is missing
После нажатия на кнопку Create WebSocket пишет WebSocket closed, а в консоли ошибка — Error during WebSocket handshake: 'sec-websocket-origin' header is missing
Однако, в Chrome 5.0.375.70 всё хорошо. Все-таки 6.x пока альфа.
Основные изменения в протоколе при переходе на 76 ревизию: elisitsky.livejournal.com/2671.html
Дело в том, что в новой редакции спецификации (ревизия 76) введен усиленный режим безопасности для предотвращения подделки запросов. Теперь новые версии браузера не принимают запросы, сделанные по старой версии протокола (ревизия 75).
Я на днях писал про это в твиттере:
twitter.com/lisitsky/status/15331679113:
twitter.com/lisitsky/status/15331373734:
Я на днях писал про это в твиттере:
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
1. Javascript казалось бы тоже ;-)
2. Извините, но мне показалось что это даже близко не тянет на аналог.
3. Возможно я скажу банальность, но fork() это функция уровня ядра операционной системы, и PHP никаким боком не влияет на него. Если у вас процессы работают на одном ядре, когда другие ядра idle, копайте в сторону ядра.
2. Извините, но мне показалось что это даже близко не тянет на аналог.
3. Возможно я скажу банальность, но fork() это функция уровня ядра операционной системы, и PHP никаким боком не влияет на него. Если у вас процессы работают на одном ядре, когда другие ядра idle, копайте в сторону ядра.
Да будущее уже давно здесь ;-)
Статья — habrahabr.ru/blogs/webdev/79038/
Пример — chat.websockets.ru
Статья — habrahabr.ru/blogs/webdev/79038/
Пример — chat.websockets.ru
Будущее давно здесь. Но не в РНР, а в Эрланге :)
Кстати, весьма полезное улучшение.
Грамотный и удобный fall-back для тухлых клиентов — очень полезная вещь на «переходный период», пока еще не все браузеры имеют нативную поддержку Web Sockets, и еще не все админы корпоративных сетей научились настраивать под них прокси-сервер.
Грамотный и удобный fall-back для тухлых клиентов — очень полезная вещь на «переходный период», пока еще не все браузеры имеют нативную поддержку Web Sockets, и еще не все админы корпоративных сетей научились настраивать под них прокси-сервер.
посмотрел демку, а в какой момент сервер дергает клиента…
судя из листинга, если не копать, за sendFrame может быть и обычное echo.
я к тому, что не совсем удачный пример.
судя из листинга, если не копать, за sendFrame может быть и обычное echo.
я к тому, что не совсем удачный пример.
Возможно, но это лишь пример. Ведь отправка и прием друг от друга не зависят, соответственно сервер шлет пакет в любой момент, и то что он во времени близок к моменту отправки пакета клиентом на сервер — никак не влияет на суть.
> судя из листинга, если не копать, за sendFrame может быть и обычное echo.
Суть в том что 'pong' идет не ответом на 'pong', а в ответ на другой запрос (poll).
> судя из листинга, если не копать, за sendFrame может быть и обычное echo.
Суть в том что 'pong' идет не ответом на 'pong', а в ответ на другой запрос (poll).
ох уж этот брОузер
замечательно!
зы: может стоит добавить в теги «js»?
зы: может стоит добавить в теги «js»?
а смысл серверной части, если прозрачной должна быть работа с клиентской?
а кроме чатов и игр где это еще может использоваться?
Хороший вопрос. Навскидку:
— Коллаборативные приложения когда несколько человек одновременно редактируют один и тот же документ, там важно получать непрерывный поток изменений с минимальной задержкой.
— Уведомления о чем бы то ни было.
— Отображение данных в системах мониторинга.
— Коллаборативные приложения когда несколько человек одновременно редактируют один и тот же документ, там важно получать непрерывный поток изменений с минимальной задержкой.
— Уведомления о чем бы то ни было.
— Отображение данных в системах мониторинга.
а между двумя клиентскими частями можно открыть веб-сокет, чтобы организовать видеосвязь без сервера?
Теоретически можно, флеш умеет биндить порт. Только непонятно зачем там вебсокет =) Это же надстройка над HTTP, а зачем двум клиентам HTTP? Это всё равно что целоваться через полиэтиленовый пакет.
да, флеш умеет п2п, и не только теоретически.
Про Server Events забыли, которые в «Опере» есть.
Спасибо! Поддержка появится скорее всего уже завтра.
P.S. хотя это тот же iframe только сбоку.
Не обижайтесь, но мое лично мнение Server Sent Events — это ненужный шлак.
Это как бы улучшенный стриминг, имеющий все проблемы обычного стриминга.
Кроме того, реализация в опере неправильная — тег по стандарту должен называться по-другому dev.w3.org/html5/eventsource/
Это как бы улучшенный стриминг, имеющий все проблемы обычного стриминга.
Кроме того, реализация в опере неправильная — тег по стандарту должен называться по-другому dev.w3.org/html5/eventsource/
А мне-то чего обижаться? Я к «Опере» отношения не имею. По замечаниям:
1) если это входит в стандарт, это всё равно придётся реализовать
2) когда в «Опере» реализовывали, то стандарт был другим.
1) если это входит в стандарт, это всё равно придётся реализовать
2) когда в «Опере» реализовывали, то стандарт был другим.
1) мне кажется, что этот стандарт умрет. Т.к. это полумеры. Сейчас есть веб сокеты — технология на порядок превосходящая SSE.
2) Оперщики поспешили. Начали делать, когда еще ничего не было известно.
2) Оперщики поспешили. Начали делать, когда еще ничего не было известно.
1) Может и умрёт, может и нет. Он простенький, в некоторых случаях его хватает.
2) Все спешат. HTML5 не принят, CSS3 — тоже. Ещё многое может поменяться. Вот в SSE уже поменялось, в VIDEO ещё не пришли к тому какой будет кодак, а все уже навтыкали поддержку в браузер. Даже border-raduis и тени везде по-разному работают.
2) Все спешат. HTML5 не принят, CSS3 — тоже. Ещё многое может поменяться. Вот в SSE уже поменялось, в VIDEO ещё не пришли к тому какой будет кодак, а все уже навтыкали поддержку в браузер. Даже border-raduis и тени везде по-разному работают.
Кажущаяся вам непомерной сложность лонг поллинга проистекает из отсутствия в PHP родных примитивов синхронизации и конструкций контроля конкурентности помимо C-шных. Именно поэтому невозможно реализовать на PHP такую штуку, как например продолжения, которые позволяют абстрагироваться от long-polling'a жить в прекрасном мире без костылей и ужасов.
Предупреждая комментарии по поводу того, что это можно сделать написав горы C-стайл кода, скажу, что использование процессов уровня ядра для таких мелких взаимодействий, как отправка и приём небольших порций данных, как минимум неэффективно, а написание собственного планировщика потоков на PHP как минимум глупо.
Предупреждая комментарии по поводу того, что это можно сделать написав горы C-стайл кода, скажу, что использование процессов уровня ядра для таких мелких взаимодействий, как отправка и приём небольших порций данных, как минимум неэффективно, а написание собственного планировщика потоков на PHP как минимум глупо.
например какой то forex отдает какую то статистику только для своего домена, что будет мне мешать получать эту статистику?
За 5 мин напишу промежуточный модуль который будет получать эти данные подменяя Origin, и после получения данных выводить информацию непосредственно уже на свой сайт.
Клиент -> Мой сервер -> подмена Origin -> forex
forex -> Мой сервер -> Клиент
Как избежать этого?
За 5 мин напишу промежуточный модуль который будет получать эти данные подменяя Origin, и после получения данных выводить информацию непосредственно уже на свой сайт.
Клиент -> Мой сервер -> подмена Origin -> forex
forex -> Мой сервер -> Клиент
Как избежать этого?
Что значит только для своего домена? На странице стоит какая-то ajax обновлялка, которая подгружает данные с сервера?
В таком случае вы можете уже сейчас тырить с нее данные :)
Просто закачиваетет данные CURL- ом и все. Потому что ограничение на домен проверяется браузером.
В таком случае вы можете уже сейчас тырить с нее данные :)
Просто закачиваетет данные CURL- ом и все. Потому что ограничение на домен проверяется браузером.
Обрабатывая заголовок Origin: сервер будет решать отдавать контент или нет.
Вопрос состоит в том как мне защитить данные.
Я хочу отдавать контент с сервера только тем клиентам которые находятся на моем сайте.
Вопрос состоит в том как мне защитить данные.
Я хочу отдавать контент с сервера только тем клиентам которые находятся на моем сайте.
Клиенты сидят дома с чашкой кохва в руке, а не находятся у вас на сайте ;-) Никак.
хм, нужно будет добавит еще один заголовок, какой то хеш, который будет генерироваться javascript'ом при заходе на сайт и передаваться
на сервер. И в момент генерации куда то сохранять на сервере. И когда происходить соединение с web-socket сравнивать совпадение.
на сервер. И в момент генерации куда то сохранять на сервере. И когда происходить соединение с 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 соединение. Если соединение прервано
ключ уже не валидный.
Например когда клиент заходит на страничку, 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
Давайте проясним задачу.
Вам нужно сделать на сайте некий информер, который с помощью веб сокетов будет получать данные с сервера и показывать их пользователю. При этом вы не хотите, чтобы этот информер можно было легко скопировать на другую веб-страницу где бы он показывал то же самое. Верно?
Вопрос: ваши данные публично доступны? Они отдаются всем пользователям вашего сайта или только определенным?
Вам нужно сделать на сайте некий информер, который с помощью веб сокетов будет получать данные с сервера и показывать их пользователю. При этом вы не хотите, чтобы этот информер можно было легко скопировать на другую веб-страницу где бы он показывал то же самое. Верно?
Вопрос: ваши данные публично доступны? Они отдаются всем пользователям вашего сайта или только определенным?
Верно я не хочу чтобы кто попало мог у себя на сайте создать web-socket и конектится к моему серверу.
Что касается публичности, неважно, пусть грабит хоть весь сайт.
Что касается публичности, неважно, пусть грабит хоть весь сайт.
ну тогда только как вы уже и сказали. Добавлять в заголовок какое-то поле с «секретным» хэшем
Это как раз ничего не даст — потому что тот самый заголовок точно так же можно вставить. Алгоритм шифрования и ключи не помогут — т.к. если это делает на стороне клиента, то вскрыть их не проблема.
Нужно использовать возможности протокола для ограничения. Это намного проще и надежнее.
Нужно использовать возможности протокола для ограничения. Это намного проще и надежнее.
чтобы его вставить вам нужно его узнать + он уникален для каждой сессии. Второй раз уже не используешь.
алгоритм работает на стороне сервера, на стороне клиента нету алгоритма.
Вы для себя подробно распишите схему работы.
она уже расписана, выше
> Javascript в данном примере играет роль шифрования ключа и определения что именно браузер зашол на сайт, а не самописный скрипт, как это сделать вариантов много.
подделывается на стороне клиента, потому что алгоритм открыт и все данные открыты.
подделывается на стороне клиента, потому что алгоритм открыт и все данные открыты.
ключ делается на сервере, java лишь его маскирует и определяет что именно браузер зашел на сайт а не скрипт.
ну а что тогда мешает злоумышленнику также маскироваться с помощью скрипта?
ничего не мешает, вопрос в том как вы получите ключ?
а как вы? Если по какому то секретному каналу то тогда это ничем практически не отличается от обычной аутентификации, а если публичным обарзом — я его также получу.
Ключ вы получите если зайдете только браузером, а не скриптом на мой сайт.
так скрипт то будет полностью подделываться под браузер. Со всеми заголовками и прочим.
это уже мелочи, вариантов как отличить скрипт от браузера много. Что касается остального то вам придется писать новый браузер.
> вариантов как отличить скрипт от браузера много
хоть 1 надежный
хоть 1 надежный
Выпейте яду. А потом откройте для себя программирование с webkit.
выпил, пишите свой новый браузер, с поддержкой
css, audio,video,forms,… а потом подумаете стоило
его начинать.
css, audio,video,forms,… а потом подумаете стоило
его начинать.
Зачем писать новый броузер? Чтобы не вникая в суть вашего javascript-кода заставить программу «зайти на сайт», «нажать кнопку» и получить нужные данные не нужно писать новый броузер. Достаточно написать простенький скрипт на основе webkit.
не вопрос, но перед тем как вам отдать ключ, javascript будет делать проверку на поддержку вашим скриптом css, audio,video,forms и всех других
технологий корыте поддерживаются настоящими браузерами их десятки. Необязательно проверку всех, рандомно одну или две.
технологий корыте поддерживаются настоящими браузерами их десятки. Необязательно проверку всех, рандомно одну или две.
а как сервер будет узнавать что поддерживаю? Только получением каких то пактов данных. Что мне мешает на все проверки всегда отдавать ответы TRUE ну или какую там сигнатуру вы ждете в случае если проверка прошла?
А здесь и вся соль, чтобы узнать нужно будет тратить свое время, чтобы понять как все работает.
Система станет уязвима если вы зделаете полноценный эмулятор браузера, это означает что вы должны будете выполнить все сценарии которые вам отдаст сервер при первом заходе. На сервере я смогу регистрировать что вам было отдано.
И потом парсить постоянно сайт это не выход, так как можно бесконечно долго менять содержимое странички, меня все компоненты.
Система станет уязвима если вы зделаете полноценный эмулятор браузера, это означает что вы должны будете выполнить все сценарии которые вам отдаст сервер при первом заходе. На сервере я смогу регистрировать что вам было отдано.
И потом парсить постоянно сайт это не выход, так как можно бесконечно долго менять содержимое странички, меня все компоненты.
да не надо ничего парсить. Я один раз посмторю что отдает назад на сервер ваш клиентский сценарий и буду отдавать тоже самое. Даже если вы будете использовать какое-то локальное шифрование с переменным ключом я тупо скопирую этот код из вашего скрипта — исходники его у меня все равно есть.
а если я ничего отдавать не буду?
если не отдавать как тогда сервер узнает что проверка прошла успешно и этому клиенту можно передавать данные?
а это вам никто не скажет, вам придется сделать полноценный браузер, мало ли я там напридумывал.
вы для начала придумайте как вы будете своему серверу «говорить» что валидация прошла успешно. А уж потом мне.
При заходе на страничку запускается python скрипт который генерит ключ и передает на страничку и копию хранит у себя. При условии что вы зашли браузером или эмулятором только тогда на страничке будет ключ.
Когда вы инициализируете web-sock соединение передается на сервер этот ключ.
Как определить что вы именно зашли браузером вариантов много, но их все можно подделать. Поэтому каждый раз будет новая проверка. Вам придется каждый раз ее искать.
Когда вы инициализируете web-sock соединение передается на сервер этот ключ.
Как определить что вы именно зашли браузером вариантов много, но их все можно подделать. Поэтому каждый раз будет новая проверка. Вам придется каждый раз ее искать.
я веду к тому что не только с помощью javascript можно определить скрипт зашел на сервер или браузер. Есть еще десятки других способов.
Если больше подумать то их и сотни можно найти.
А парсить придется так как ключ генерируется моим сервером, да и можно время жизни ему поставить.
Если больше подумать то их и сотни можно найти.
А парсить придется так как ключ генерируется моим сервером, да и можно время жизни ему поставить.
расскажите хотя бы еще один способ из десятка который я не смогу подделать?
Вы так и не поняли идеи.
Вы сможете подделать все мои способы.
Я могу их периодично менять, их будет бесконечное число.
Вам придется по новой анализировать код.
Проще написать полноценный эмулятор, а это уже ничем не будет отличатся от баузера.
Вы сможете подделать все мои способы.
Я могу их периодично менять, их будет бесконечное число.
Вам придется по новой анализировать код.
Проще написать полноценный эмулятор, а это уже ничем не будет отличатся от баузера.
любая ваша технология всегда будет упираться в проблему «бутылочного горлышка» в виде посылки запросов к серверу, которые у меня как на ладони.
серверу посылается только один запрос это ключ, который вам предоставляется при заходе на страничку. Но этот ключ ничего не стоит если вы не прошли проверку на валидность браузера. Этот ключ и есть разрешением на открытие web-socket
Например валидность браузера можно определить выполнение какого то javascrit, а можно и по другому, каждый раз проверка будет меняется, и вы будете каждый раз ее искать и тратить время на анализирование сайта, что сведет на нет всю идею. Вам попросту придется написать свой браузер.
Например валидность браузера можно определить выполнение какого то javascrit, а можно и по другому, каждый раз проверка будет меняется, и вы будете каждый раз ее искать и тратить время на анализирование сайта, что сведет на нет всю идею. Вам попросту придется написать свой браузер.
валидация все равно происходит на клиенте, значит мне доступен ее алгоритм. В самом крайнем случае если вы будете менять ее шибко часто, ну тогда нужно будет плагин к браузеру, это максимум.
она будет меняться каждый раз когда вы зайдете на страничку.
Ну а как браузер прикрутить к apache серверу?
Ведь идея стоит в том чтобы скрипт п*здил контент с чужого сайта по методу web-socket.
Клиент заходит на А сайт устанавливается web-socket соединение с этим же А сервером. А сервер п*здит контен с В сервера. По вашему нужно на А сервер
поставить браузер с плагином и прикрутить его каким то образом к apache. Я это мало представляю.
В данной дискусии я вижу только один выход написания скрипта эмулятора который будет заменять браузер.
Или же переписывание исходников какого то свободного браузера чтобы можно его было прикрутить к вебсерверу.
Ну а как браузер прикрутить к apache серверу?
Ведь идея стоит в том чтобы скрипт п*здил контент с чужого сайта по методу web-socket.
Клиент заходит на А сайт устанавливается web-socket соединение с этим же А сервером. А сервер п*здит контен с В сервера. По вашему нужно на А сервер
поставить браузер с плагином и прикрутить его каким то образом к apache. Я это мало представляю.
В данной дискусии я вижу только один выход написания скрипта эмулятора который будет заменять браузер.
Или же переписывание исходников какого то свободного браузера чтобы можно его было прикрутить к вебсерверу.
то есть проверка делается на стороне клиента?
клиент шлет ключ на сервер в дополнительном заголовке, на сервере этот ключ проверяется валидный ли он.
Выше я уже написал как оно должно работать.
Выше я уже написал как оно должно работать.
так кто генерирует ключ?
Если сервер, то я зайду своим скриптом и получу его.
Если клиент — я просто посмотрю как он его генерирует и буду делать тоже самое.
Если сервер, то я зайду своим скриптом и получу его.
Если клиент — я просто посмотрю как он его генерирует и буду делать тоже самое.
выше я описал схему.
Ключ сгенерил сервер, вы его получите, если вы
зашли браузером на сайт и только им, отличить браузер от скрипта элементарно, вариантом миллион.
Ключ будет уникальным для каждого клиента, и время жизни его только на одну сессию, тобиш при повтором обновлении странички или закрытии web-socketa ключь уже не валидный
Ключ сгенерил сервер, вы его получите, если вы
зашли браузером на сайт и только им, отличить браузер от скрипта элементарно, вариантом миллион.
Ключ будет уникальным для каждого клиента, и время жизни его только на одну сессию, тобиш при повтором обновлении странички или закрытии web-socketa ключь уже не валидный
могу вас заверить что мой скрипт не будет никак отличаться от браузера. В конце-концов это может быть чутка подправленный браузер. Начиная от помощи плагинов, заканчивая правкой исходников и т. п.
и вы забыли что его еще нужно прикрутить к веб-серверу.
Чтобы работала схема.
Клиент -> Мой сервер -> подмена Origin -> forex
Где «подмена Origin» вам нужно умудриться прикрутить свой браузер с плагинами.
Настоящий браузер будет проблематично туда прикрутить, что касается скрипта который будет эмулировать работу браузера, это и есть полноценный браузер, если у вас такой есть поделитесь.
Чтобы работала схема.
Клиент -> Мой сервер -> подмена Origin -> forex
Где «подмена Origin» вам нужно умудриться прикрутить свой браузер с плагинами.
Настоящий браузер будет проблематично туда прикрутить, что касается скрипта который будет эмулировать работу браузера, это и есть полноценный браузер, если у вас такой есть поделитесь.
Эта проблема уже решена в протоколе :)
Как раз для проверки откуда идет подключение сделан заголовок Origin. Когда вы его получаете, просто проверьте, что подключение идет с вашего домена. Если нет, то имеете право сбросить подключение.
Либо же выдать свой Origin — если они не совпадут, браузер сам должен закрыть подключение.
Как раз для проверки откуда идет подключение сделан заголовок Origin. Когда вы его получаете, просто проверьте, что подключение идет с вашего домена. Если нет, то имеете право сбросить подключение.
Либо же выдать свой Origin — если они не совпадут, браузер сам должен закрыть подключение.
Origin всегда одинаковый. Любой сможет воспользоваться.
Вы уверены?
Расскажете как именно это можно сделать?
Расскажете как именно это можно сделать?
Кончайте флудить =) У человека в голове каша, и ее так просто не удалить.
Заголовок Origin отсылает браузер клиента, и в нем передается URL с которого была вызвана сессия web-sock.
Именно на браузер будет возложена задача чтобы этот заголовок был правильным. Но мне ничего не мешает его подменить, написать скрипт и слать
любой Origin
Именно на браузер будет возложена задача чтобы этот заголовок был правильным. Но мне ничего не мешает его подменить, написать скрипт и слать
любой Origin
ЯваСкриптом? напишете такой?
сервер я предоставлю.
сервер я предоставлю.
Мой самый первый пост
Клиент -> Мой сервер -> подмена Origin -> forex
причем здесь javascript?
В данной схеме я буду п*здить контент с forex
и показывать на своем сайте, п*здить я его буду с помощью скрипта на писаного на любом языке (python, php,///)
В данной схеме мой сервер будет выступать в качестве посредника.
Клиент -> Мой сервер -> подмена Origin -> forex
причем здесь javascript?
В данной схеме я буду п*здить контент с forex
и показывать на своем сайте, п*здить я его буду с помощью скрипта на писаного на любом языке (python, php,///)
В данной схеме мой сервер будет выступать в качестве посредника.
ну я уже описал как я сделал это в моем сервере, но это действительно ничего нового, просто обычная авторизация, никакой публичности.
Кто мешает аутентифицировать коннект?
Например, так сделано у меня в чате. Вначале клиент подключается и начинает получать события из чата: изменение списка пользователей, новые сообщения и так далее.
Если он хочет писать, то ему надо авторизоваться на сервере. Для этого он отправляет специальный запрос, сервер его проверяет и назначает данному коннекту данного пользователя. Можно сделать проверку по спец. ключику, логину/паролю и так далее.
Так же, поскольку мы знаем, какое подключение какому клиенту принадлежит, то мы можем контролировать их количество — например не позволять подключаться повторно, пока работает текущее соединение. Кроме того, при необходимости можно очень легко отключить клиента — просто сбросив его соединение.
Например, так сделано у меня в чате. Вначале клиент подключается и начинает получать события из чата: изменение списка пользователей, новые сообщения и так далее.
Если он хочет писать, то ему надо авторизоваться на сервере. Для этого он отправляет специальный запрос, сервер его проверяет и назначает данному коннекту данного пользователя. Можно сделать проверку по спец. ключику, логину/паролю и так далее.
Так же, поскольку мы знаем, какое подключение какому клиенту принадлежит, то мы можем контролировать их количество — например не позволять подключаться повторно, пока работает текущее соединение. Кроме того, при необходимости можно очень легко отключить клиента — просто сбросив его соединение.
Только авторизация.
Все остальное забирается элементарно.
Все остальное забирается элементарно.
Ничего не мешает и не должно мешать.
Аналогичный проект на Java Project Atmosphere
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebSocket: будущее уже здесь!