[Описание Rest Api]

mariman, подумалось вот: неплохо бы для json запросов добавить опциональный параметр callback (или типа того)

1) google-style (http://code.google.com/intl/ru/apis/gdata/docs/json.html)

2) реально создавать "тонкие" клиенты без дополнительного серверного скрипта для проксирования запросов

[KartinaTV player 2.68]

Здраствуйте! Помогите плиз разобраться,как смотреть тв-онлайн-скачала вашу прогу,но все равно ничего не работает -выдает (Kartina.tv Client API reports some errors-Host not Found)

В чем ошибка? В сафари и Фирефоксе тоже выдает не установлен плагин-хотя плагины скачала?! Система Mac OS-Спасибо!

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

2) VLC установлен? в настройках VLC-record правильно прописан?

[Описание Rest Api]

Хотелось бы заметить, что Картина в будущем может захотеть сделать отдельный поток с пониженным битрейтом для просмотра на смартфонах. Как будет отражаться использование SSL на мобильных девайсах, сказать затрудняюсь, может, у Вас есть опыт?

я так понимаю, что речь идет об использовании защищенного соединения исключительно для авторизации, что нормально.

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

[Описание Rest Api]

Вопрос: каким таким образом клиент увидит свой реальный IP чтобы соорудить подобный хэш?

 

dig +short myip.opendns.com @resolver1.opendns.com

или типа того (даже стянуть http://whatismyip.com и отпарсить оттуда адрес вполне сойдет)

те, кто будут думать, что локальный адрес и есть внешний, вряд ли будут способны написать что-то достойное. так что можно этот сегмент игнорировать.

ну или пусть используют ssl..

 

хотя, дело, конечно, хозяйское..

наше дело предложить ©

[Описание Rest Api]

Может все-таки мы, как разработчики, лучше знаем где у нас нагрузка больше... Мы проводили тесты перед тем как определиться с архитектурой API и пришли к выводу что механизм сессии оптимален. Есть много нюансов в авторизации, которые просто невозможно делать каждый раз. Например биллинг...

то, что механизм предварительной авторизации оправдывает себя -- я с этим и не думал спорить. это доказано многочисленными практиками экономии, как на спичках, так и на серьезных расходах рессурсов. вполне можно считать это стандартом "де факто".

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

к слову, вот скажите откровенно, храните ли вы в сессии существенно больше биллинг-рилэйтед информации, чем ID аккаунта? вопрос риторический..

 

Будем объективны. Риски, хоть и малые, но все-таки есть. Мы обязаны предоставить безопасное соединение. Пока сама учетная запись будет объектом купли-продажи, к ней будет интерес злоумышленников.<br /><br />

действительно похвально. как на счет альтернативного способа авторизации по хешу (предложенного мной выше в теме)? дешево и сердито.. в перспективе решает ряд вопросов для авторизации с убогих девайсов имеющих проблемы с ssl соединениями.

 

не в инструментах речь. Да. только через такой проксик только и можно сделать плейлист.

вопрос в том, что "будет ли такая реализация считаться паразитической"? ибо простой shell скрипт открывающий таким образом канал пишется за 3 минуты. а вот скрипт с сохранением промежуточного состояния сесси между получением списка каналов, просмотром программки и переключением тех самых каналов будет писаться дольше.

[Описание Rest Api]

1. доп. нагрузка на сервер (потому как при логине и пароле производится масса проверок);

расшифрую:

выборка по ид или паре логин/пароль нагружает сервер БД практически одинаково (при соответветствующих индексах). а проверять состояние аккаунта юзера, по хорошему, все равно надо, вне зависимости от того, залогинен он или нет..

 

2) безопасность. Вообще посылать пароль в открытом виде через УРЛ пока не рекомендуется и, скорее всего, в будущем будет запрещено

тут полностью поддерживаю. хотя, будем объективны, риски малы. скорее всего в ssl особого смысла нет, но шуровать пароль в виде хеша md5 из пароля + адреса подсети (пусть не в виде основного, до дополнительного варианта авторизации) было бы здорово. типо:

$subnet = implode('.', array_slice(explode('.', $_SERVER['REMOTE_ADDR']), 0, 3));
$passMD5 = md5($password . $subnet);

 

По первой причине могу добавить: если будет паразитическая нагрузка в виде "дергания" на каждый чих логина и пароля - мы вынуждены будем ужесточать меры на ограничения.

упростите (опишите более детально) требования к авторизации и все станет гораздо проще. дайте людям понять, что "не куки" будут работать. как вариант, добавьте возможность (и документируйте её) передавать ид сессии прямо в урл.

развитие API -- это большой шаг, как для развитие вашего web-интерфейса, так и для привлечения сторонних разработчиков (все-таки, вы продаете сервис, а не приставки к сервису), что принесет дополнительных клиентов.

 

<br />Как можно сделать ссылку для VLC, то есть плейлист?<br />

при помощи "паразитической нагрузки" проксировав запрос на канал через простой скриптик который авторизируется и перезапросит ссылку на канал. писать паразита можно на любом языке программирования, вплоть до shell (wget + grep + awk справятся аж бегом)

[Описание Rest Api]

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)

Для идентификации и создании сессии было решено использовать стандартный механизм HTTP сессий с поддержкой COOKIE.

означает ли это, что вы форсировали параметр session.use_only_cookies? или же только пугаете, и можно будет спокойно передавать параметр типа MWARE_SSID=4cqi1rt010uf4bi2okmflpavs7 обычным параметром запроса (что иногда предпочтительнее)