Комментарии 25
А график именно ваш? Если да, то это круто!
чуть более безопасный вариант тут
Вам удалось победить постоянный значок подгрузки страницы в некоторых браузерах? Мне пришлось из-за этой неприятной фичи отказаться от faye в пользу socket.io и его flash-прокладки.
Думал тоже на выходных про faye написать :) Полезная штука и к рельсам прикручивается очень просто.
1. почему нельзя тут использовать вебсокеты?
2. почему было руби взято за основу?
3. почему нельза делить диспечеров, чтоб к каждому попадала только часть заявок
4. какую базу использовали
5. почему облако?
2. почему было руби взято за основу?
3. почему нельза делить диспечеров, чтоб к каждому попадала только часть заявок
4. какую базу использовали
5. почему облако?
1. взят универсальный транспорт. так они гарантируют, что будет всегда работать.
2. Здесь неполность статьи — следует отметить, что faye имеет два вида сервера в стандартной поставке — nodejs и руби. И умеет масштабировать используя редис из коробки в одну строчку кода.
2. Здесь неполность статьи — следует отметить, что faye имеет два вида сервера в стандартной поставке — nodejs и руби. И умеет масштабировать используя редис из коробки в одну строчку кода.
1. Мы настолько глубоко не копали. Спасибо за наводку, глянем еще
2. Может из заголовка и не ясно, но статья про конкретный случай, в котором не нужен nodejs и redis.
2. Может из заголовка и не ясно, но статья про конкретный случай, в котором не нужен nodejs и redis.
в faye есть возможность автоматического выбора протокола в зависимости от браузера клиента — это очень удобно и работает везде, рекомендую. websocket все же добро и поддерживается все большим числом браузеров — нет паузы между потерей соединения и его восстановлением, как при long pooling
единственно, если вы используете nginx, будут проблемы с websockets, но как их решить я недавно написал в посте
удачи в разработке!
единственно, если вы используете nginx, будут проблемы с websockets, но как их решить я недавно написал в посте
удачи в разработке!
1. Можно, наверное, когда у всех браузер будет свежий. Пока это не так, у некоторых IE6 вообще, и полагаться на это мы не осмелились. Попозже приделаем, когда абоненты пообновляются.
2. Потому что все приложение на RoR написано.
3. Потому что диспетчера находятся в астерисковской round-robin очереди и далеко не факт, что рассерженный клиент, заказавший такси 20 минут назад попадет на того же диспетчера, что и в первый раз. Следовательно — все диспетчера должны обладать полной информацией.
4. MySql
5. У нас все серваки арендованные и в облаке.
2. Потому что все приложение на RoR написано.
3. Потому что диспетчера находятся в астерисковской round-robin очереди и далеко не факт, что рассерженный клиент, заказавший такси 20 минут назад попадет на того же диспетчера, что и в первый раз. Следовательно — все диспетчера должны обладать полной информацией.
4. MySql
5. У нас все серваки арендованные и в облаке.
1. Можно, наверное, когда у всех браузер будет свежий. Пока это не так, у некоторых IE6 вообще, и полагаться на это мы не осмелились. Попозже приделаем, когда абоненты пообновляются. — У вас же деспечера конечное число. пересадите их на вебсокеты, у коллеги система мониторинга бана Ип адресов написана на вебсокетах, там одновременно опрашиваються 1024 Ип адреса и показываеться состояние
2. ror имхо не хороший выбор для высоконагреженного приложения
3. к мускулу таже притензия, уж больно часто он играет злую шутку при увеличении количества данных.
5. посчитайте сколько вы тратите на облако и на выделенный + админ ))))
2. ror имхо не хороший выбор для высоконагреженного приложения
3. к мускулу таже притензия, уж больно часто он играет злую шутку при увеличении количества данных.
5. посчитайте сколько вы тратите на облако и на выделенный + админ ))))
еще на railscasts можно в живую посмотреть про faye
Создаем новый файлик с текстомЭто где это вы такое узрели? Это «защита» от того чтобы никто кроме приложения не мог постить в каналы.
FAYE_TOKEN = "anything"
Это задает строку, по которой сервер сообщений будет отличать одно приложение от другого, если их станет несколько. Вместо «anything» можно написать что угодно, только чтобы потом не запутаться.
«Защита» потому что этот самый токен будет передаваться всем вместе с сообщением. Чтобы этого не было нужно этот токен в ServerAuth#incoming удалять из сообщения перед отправкой подписчикам. Еще неплохо этот токен создавать динамически и периодически менять.
Далее, никто не мешает клиенту подписаться на все каналы ('/*') и получать то, что ему не предназначено. Лечится это дополнительной проверкой в ServerAuth#incoming примерно так:
message['error'] = 'Forbidden' if message['channel'] == '/meta/subscribe' && message['subscription'] =~ /\*/Следующий момент: т.к. faye-сервер у вас запущен по адресу moesuperprilozhenie.ru:9292, то имеем CORS. Чтобы Rack правильно его обрабатывал, нужно поставить гем rack-cors и прописать в конфиге faye:
require 'rack/cors'
use Rack::Cors do
allow do
origins '*'
resource '/faye', :headers => :any, :methods => [:get, :post, :options]
end
end
(Как вариант это можно решить через прокси на front-end)
FAYE_TOKEN не очень катит на защиту по моему скромному: без шифрации и при передаче через открытые каналы это просто идентификатор приложения. Хотя, если шифрация есть а я про нее просто не знаю — тогда да, защита. Как тут кто-то писал, есть более безопасный вариант. В нашем случае мы защищаемся файрволом, потому что постинг идет только с сервера приложений.
Далее. за наводку на rack-cors спасибо, но у нас и так работает. Возможно, различие только в порте не считается кросс-доменом? А может админ при развертывании на боевом сделал как раз проксирование на nginx, спрошу его.
Про защиту от подписки на все каналы — это Вы верно подметили, так и сделаем, спасибо. Хотя у нас сейчас один только канал, но лучше сразу сделать правильно чем потом искать.
Далее. за наводку на rack-cors спасибо, но у нас и так работает. Возможно, различие только в порте не считается кросс-доменом? А может админ при развертывании на боевом сделал как раз проксирование на nginx, спрошу его.
Про защиту от подписки на все каналы — это Вы верно подметили, так и сделаем, спасибо. Хотя у нас сейчас один только канал, но лучше сразу сделать правильно чем потом искать.
FAYE_TOKEN не очень катит на защиту по моему скромному: без шифрации и при передаче через открытые каналы это просто идентификатор приложения. Хотя, если шифрация есть а я про нее просто не знаю — тогда да, защита.Не понял смысла фразы. В том коде, что вы привели ServerAuth и FAYE_TOKEN нужны для следующего: если кто-то постит в канал сообщение, то в нем проверяется наличие токена и если он есть и равен FAYE_TOKEN, то сообщение отправляется остальным подписчикам. Иначе отправителю приходит сообщение об ошибке. Далее в оригинальном коде сделано предположение, что FAYE_TOKEN знает только сервер и только он может постить в каналы.
Проблема того куска кода в том, что токен не удаляется из исходного сообщения и отправляется всем подписчикам. Далее, открыв в любимом браузере любимый инструмент мониторинга траффика (Firebug, etc.), любой подписчик может узнать этот токен и начать постить в любой канал (при помощи клиентского API) все, что его душеньке будет угодно. Проблема решается, если в ServerAuth#incoming просто удалить этот токен из сообщения перед непосредственной отправкой подписчикам.
Faye Reagan… Эх, пятница
Спасибо за приподнятое настроение )
Спасибо за приподнятое настроение )
Вопрос: как реализовать авторизацию на faye-сервере через cookie-сессию, хранящуюся в Redis?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Faye как способ не задолбать свой сервер