Eugene

mariman, подумалось вот: неплохо бы для json запросов добавить опциональный параметр callback (или типа того) 1) google-style (http://code.google.com/intl/ru/apis/gdata/docs/json.html) 2) реально создавать "тонкие" клиенты без дополнительного серверного скрипта для проксирования запросов

1) кодеки для браузеров устанавливали согласно этой инструкции? http://forum.kartina.tv/index.php?showtopic=2301 2) VLC установлен? в настройках VLC-record правильно прописан?

я так понимаю, что речь идет об использовании защищенного соединения исключительно для авторизации, что нормально. потому что гонять трафик через SSL (особенно на мобильных девайсах) -- страшный overload на обе стороны. а чахлые девайсы просто не потянут такой нагрузки (декодирование трафика, декодирование потока + проигрывание потока)

dig +short myip.opendns.com @resolver1.opendns.com или типа того (даже стянуть http://whatismyip.com и отпарсить оттуда адрес вполне сойдет) те, кто будут думать, что локальный адрес и есть внешний, вряд ли будут способны написать что-то достойное. так что можно этот сегмент игнорировать. ну или пусть используют ssl.. хотя, дело, конечно, хозяйское.. наше дело предложить ©

то, что механизм предварительной авторизации оправдывает себя -- я с этим и не думал спорить. это доказано многочисленными практиками экономии, как на спичках, так и на серьезных расходах рессурсов. вполне можно считать это стандартом "де факто". хотя, биллинг, в данном случае, это отчасти именно экономия на спичках. поскольку все равно срок годности абонемента надо сравнивать с текущим таймстемпом при каждом запросе API, а будет ли при этом выполнен дополнительный запрос к базе (по первичному ключу!) или нет (и значение будет извлечено из некого кеша, коим и является механизм сессий) -- это уже детали реализации. к слову, вот скажите откровенно, храните ли вы в сессии существенно больше биллинг-рилэйтед информации, чем ID аккаунта? вопрос риторический.. действительно похвально. как на счет альтернативного способа авторизации по хешу (предложенного мной выше в теме)? дешево и сердито.. в перспективе решает ряд вопросов для авторизации с убогих девайсов имеющих проблемы с ssl соединениями. вопрос в том, что "будет ли такая реализация считаться паразитической"? ибо простой shell скрипт открывающий таким образом канал пишется за 3 минуты. а вот скрипт с сохранением промежуточного состояния сесси между получением списка каналов, просмотром программки и переключением тех самых каналов будет писаться дольше.

расшифрую: выборка по ид или паре логин/пароль нагружает сервер БД практически одинаково (при соответветствующих индексах). а проверять состояние аккаунта юзера, по хорошему, все равно надо, вне зависимости от того, залогинен он или нет.. тут полностью поддерживаю. хотя, будем объективны, риски малы. скорее всего в ssl особого смысла нет, но шуровать пароль в виде хеша md5 из пароля + адреса подсети (пусть не в виде основного, до дополнительного варианта авторизации) было бы здорово. типо: $subnet = implode('.', array_slice(explode('.', $_SERVER['REMOTE_ADDR']), 0, 3)); $passMD5 = md5($password . $subnet); упростите (опишите более детально) требования к авторизации и все станет гораздо проще. дайте людям понять, что "не куки" будут работать. как вариант, добавьте возможность (и документируйте её) передавать ид сессии прямо в урл. развитие API -- это большой шаг, как для развитие вашего web-интерфейса, так и для привлечения сторонних разработчиков (все-таки, вы продаете сервис, а не приставки к сервису), что принесет дополнительных клиентов. при помощи "паразитической нагрузки" проксировав запрос на канал через простой скриптик который авторизируется и перезапросит ссылку на канал. писать паразита можно на любом языке программирования, вплоть до shell (wget + grep + awk справятся аж бегом)

1) пожалуйста, сделайте ini_set('display_errors', 0); ибо <br /> <b>Notice</b>: Use of undefined constant API - assumed 'API' in <b>/***/***/api/face.class.php</b> on line <b>15</b><br /> не то, чтобы придираюсь, просто XML не валидный получается а в дальнейшем это вас избавит от ругани простых пользователей.. 2) означает ли это, что вы форсировали параметр session.use_only_cookies? или же только пугаете, и можно будет спокойно передавать параметр типа MWARE_SSID=4cqi1rt010uf4bi2okmflpavs7 обычным параметром запроса (что иногда предпочтительнее)