API для Kartina.tv

[Arty]

Приветствую!
API для Kartina.tv еще существует и доступно для разработчиков?

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

Можно узнать что именно изменилось или получить доступ к информации об API с текущим функционалом.

(для Медиаплеера (не Dune) который в числе первых давал возможность смотреть картину по подписке - теперь поломалось).

[mariman]

API не изменилось. Добавился новый функционал - Multiroom - работа нескольких клиентов в пределах одного абонента. Существенно изменен движок сессий. Изменилось имя сессии (необходимое условия для смены сессий всех абонентов). Вцелом, устройства использующие механизм API не заметели перехода.

Можно немного подробнее о том что "поломалось"?

[alexsolo]

Как я понял, при мультидоступе при логине стала вылезать ошибка "Ошибка авторизации. Ваш абонемент используется другим устройством". При перелогине, все начинает работать корректно, и у первого пользователя трансляция не прекращается. Т.е. разработчикам надо предусмотреть этот код ошибки и перелогиниваться заново.

[Arty]

Да я пока разведку фронта работ веду.. 

Поступила "жалоба" от пользователя что перестала работать картина на приставке гдето с неделю или две. И по его же переговорам с поддержкой прояснилось что что то изменили вот с поддержкой одновременно нескольких устройств. (Да и вообще видимо отфутболили его с формулировкой о неподдержке неофициальных устройств).  А поскольку сам подписки к картине не имею, пока только веду разведку а что там могло случиться, что бы понять подписываться (хотя лично мне не нужно) или забросить не берясь исправлять

Как то противоречиво: API не изменилось <-> Существенно изменен движок сессий.

 

P.S. Раньше итак был механизм перелогинивания на приставке (если до того человек параллельно смотрел с компа например). Говорят - уже не помогает. (а я пока в слепую не проверю).

Изменено 25 марта 2014 пользователем Arty

[apodolsk]

Приветствую!

API для Kartina.tv еще существует и доступно для разработчиков?

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

Можно узнать что именно изменилось или получить доступ к информации об API с текущим функционалом.

(для Медиаплеера (не Dune) который в числе первых давал возможность смотреть картину по подписке - теперь поломалось).

Одно я опытным путем установил определенно - теперь нет возможности передавать идентификатор сессии при запросах( по крайней мере в geturl), как параметр

Стр. 4 руссого описания.

Также возможна передача параметров &<имя сессии>=<ключ сессии> через url. <Имя сессии> при этом необходимо брать из ответа пакета функции /login. Подобный метод из соображений безопасности является нежелательным, равно как и передача login методом GET

Теперь не только нежелательна, но и невозможна. Только Cookie

Изменено 25 марта 2014 пользователем apodolsk

[mariman]

Как то противоречиво: API не изменилось <-> Существенно изменен движок сессий.

 

Никаких противоречий. API - совокупность набора функций и их ответов. Движок сессий не менял набора функций и не вилял на их ответ. 

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

 

session.use_only_cookies = 0 . Стандартный механизм работы с сессиями должен принимать параметры сессии через URL. Обратите внимание на имя сессии. Оно изменилось. Возможно в этом причина проблем.

 

З.Ы. Плееры DuneHD успешно используют метод передачи идентификатора сессии через URL до сих пор. 

[Arty]

По старой памяти.. вполне возможно что и в этом дело, спасибо apodolsk .

Остается получить официальное подтверждение по этому поводу что нежелательное стало невозможным именно в недавнее время... 

Тогда хоть будет понятнее где начинать копать.

 

P.S. ок и по имени посмотрим.. (когда заполучим у пострадавшего учетные данные :о) )

Изменено 25 марта 2014 пользователем Arty

[mariman]

Да. проблему наблюдаем. Исправим в ближайшее время.

[apodolsk]

session.use_only_cookies = 0 . Стандартный механизм работы с сессиями должен принимать параметры сессии через URL. Обратите внимание на имя сессии. Оно изменилось. Возможно в этом причина проблем.

 

З.Ы. Плееры DuneHD успешно используют метод передачи идентификатора сессии через URL до сих пор. 

Проверил. Подтверждаю, если делать точно как  в описании, т.е. <Имя сессии>  брать из ответа пакета функции /login, то все ОК.

 

@mariman - Respect

[mariman]

Описание проблемы - на одном из серверов Middlware обслуживающего API сессия не передается через URL. Зависит от того на какой сервер вас отправит балансировщик. В ближайшее время исправим ситуацию.

[apodolsk]

Описание проблемы - на одном из серверов Middlware обслуживающего API сессия не передается через URL. Зависит от того на какой сервер вас отправит балансировщик. В ближайшее время исправим ситуацию.

opps    Если не все серверы из Pool одинаково обрабатывают или передают запросы, тогда жить весело...

[mariman]

Ситуация исправлена.

 

В ближайшее время будет официальный релиз в соответствующей ветке, но пока для разработчиков хотел бы донести следующее:

 

В связи с введенем фунции multiroom стал вопрос об получении данных абонента вне сессии. Необходима проверка абонента но так, чтобы не создавать абонентскую сессию и не "выбивать" клиентов, которые уже работают.

В виду этого было принято решение добавить параметр auth для метода /login

 

&auth=no - указывает на то, что сессия создаваться не должна.

 

Ответ у метода идентичен методу /login за исключением отсутствия данных сессии.

 

Для предотвращения ситуации, что в настройках абонемента можно указать битрейт для всех клиентов в пределах абонемента, введен дополнительный параметр "bitrate" битрейта для функции /get_url.  Разработчики могут выводить каналы в нужном битрейте не прибегая к установке глобального для абонемента значения.

 

/get_url?cid=2&bitrate=[320|900|1500|2500] - значение полученное из /settings?var=bitrate

 

Список возможных значений битрейта и таймшифта для конкретных каналов смотреть в ответе /channel_list

[apodolsk]

В связи с введенем фунции multiroom стал вопрос об получении данных абонента вне сессии. Необходима проверка абонента но так, чтобы не создавать абонентскую сессию и не "выбивать" клиентов, которые уже работают.

В виду этого было принято решение добавить параметр auth для метода /login

 

&auth=no - указывает на то, что сессия создаваться не должна.

Ответ у метода идентичен методу /login за исключением отсутствия данных сессии.

Попробовал - с параметром &auth=no действительно возвращает данные без сессии, но только "через раз".

В остальных случаях

RestClient on Firefox не показывает ничего, а curl on Raspbian

curl: (56) Recv failure: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt

Изменено 25 марта 2014 пользователем apodolsk

[Arty]

В моем случае таки оказалось дело в sid_name 

Три года было как в примере и вот те вдруг .. 

Оптимизаторы сократили нагрузку на 4 символа?

[gasoj]

 

В связи с введенем фунции multiroom стал вопрос об получении данных абонента вне сессии. Необходима проверка абонента но так, чтобы не создавать абонентскую сессию и не "выбивать" клиентов, которые уже работают.

В виду этого было принято решение добавить параметр auth для метода /login

 

&auth=no - указывает на то, что сессия создаваться не должна.

 

Т.е. по сути введена функция /check_user_password ?

Т.к. не понятно, зачем логиниться более 1го раза? Разве что при чрезвычайно редкой смене логина юзером.

Изменено 25 марта 2014 пользователем gasoj

[mariman]

В моем случае таки оказалось дело в sid_name 

Три года было как в примере и вот те вдруг .. 

Оптимизаторы сократили нагрузку на 4 символа?

 

Пример на то он и пример что может быть ""примерно"" как в жизни... В документации четко написано откуда брать имя сессии. Насчет 4 символов - сократили потому что надо было ИЗМЕНИТЬ имя сессии, чтобы ВСЕ абоненты переключились на новый движок сессий. Так сказать перегенерировать SID. 

 

 

т.е. по сути введена функция /check_user_password ?

Т.к. не понятно, зачем логиниться более 1го раза? Разве что при чрезвычайно редкой смене логина юзером.

 

По сути - да. Все верно. Только немного с расширенным ответом.

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

[Задавака]

В 26.03.2014 в 08:28, mariman сказал:

 

В 25.03.2014 в 20:59, Arty сказал:

В моем случае таки оказалось дело в sid_name 

Три года было как в примере и вот те вдруг .. 

Оптимизаторы сократили нагрузку на 4 символа?

Пример на то он и пример что может быть ""примерно"" как в жизни... В документации четко написано откуда брать имя сессии. Насчет 4 символов - сократили потому что надо было ИЗМЕНИТЬ имя сессии, чтобы ВСЕ абоненты переключились на новый движок сессий. Так сказать перегенерировать SID. 

 

В 25.03.2014 в 21:24, gasoj сказал:

>т.е. по сути введена функция /check_user_password ?

Т.к. не понятно, зачем логиниться более 1го раза? Разве что при чрезвычайно редкой смене логина юзером.

По сути - да. Все верно. Только немного с расширенным ответом.

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

Для брутфорсеров хорошая новость.

[mariman]

В 26.03.2014 в 17:56, Задавака сказал:

Для брутфорсеров хорошая новость.

Не очень-то. Правило 3-х неверных паролей и бан на 10 минут никто не отменял. Еще + Лимит 5 запросов в секунду. А стоит ли овчинка выделки?