Приветствую, уважаемые форумчане! С большой долей вероятности, скоро буду работать над проектом, с платными видео уроками. Заказчик хочет, чтобы платные видео уроки можно было просматривать только в личном кабинете и только оплатившим видео. Кроме того не должно быть возможности поделиться ссылкой на видео или скачать его. Доступность ссылки на сайте примерно понимаю, как реализовать. Но что касается утечки видосиков через уже оплативших... здается мне, что технически подкованный человек скачает видос, куда бы я его не залил. Хоть YT Хоть на свой сервак. Что думаете?
куда бы ни залил - тут нет отрицания да, это так в западном мире для этого придумали DRM защиты всякие, которые тоже ну... не то чтобы работают. Что делать - не понятно.
1) "сдается". 2) Вопрос стоит в сложности процедуры. Я как раз сейчас работаю над таким же по сути проектом. YT и любые другие видеохостинги сразу можешь выбросить из вариантов. Они не заинтересованы в ограничении скачивания. Во-первых, это лишние накладные расходы в плане мощностей им это не выгодно с их трафиком-то. Во-вторых, если видео уже попало на экран пользователя, ему ничего не мешает его с экрана тупо записать любым скринкапчером. У меня, в данный момент, реализован свой собственный видеохостинг. Своя серверная часть, хранилище, свой плеер, заточеный под работу с ним. Свой протокол обмена данными. Тебе тоже все это придется делать. Защитить видос от скачивания можно: 1) Одноразовые ссылки. Ну..почти одноразовые. 2) Шифрование оных, чтобы нельзя было просто взять и скопипастить. Автоматом срезает все расширения-качалки. Как косой просто. Пришла кривая ссылка? Кто-то дебажит или шчупает. Блокируй доступ. 3) Отслеживание количества использования ссылок. Суть в том, что для начала стримминга тому же html5-video компоненту нужно сделать минимум 3 запроса к медиаресурсу. Дернуть меты, проверить аудио и видеопотоки. Четвертый запрос уже будет с 206 кодом и range. Если пришел пятый - отсылай ошибку и новую шифрованную ссылку, пусть клиент делает реконнект. Если пришел шестой - блокируй доступ. 4) Отслеживание времени активности ссылки. Если между выдачей клиенту новой ссылки и запросом по ней прошло больше, скажем, 1-2 секунд, то, скорее всего твое приложение пытаются дебажить - блокируй доступ. 5) HTTPS, чтобы трафик не шел от сервера в чистом виде. 6) Отключение всевозможного кэширования. Да. Придется платить повышением нагрузки на сервер, канал и трафик-квоту. Смотря что заказчику дороже - сервер или видосы. И все такое прочее. Сейчас, чтобы скачать у меня видос, нужно писать свой клиент, который будет косить под браузер, но не отображать контент, а лить прямо на винт. Другого пути нет. Для 99.9% пользователей, даже технически подкованных, это не вариант. Оставшемуся 0.1% едва ли будет интересно так заморачиваться ради видеоуроков. Это не такой прям массовый продукт. Усилия едва ли окупятся. На том и стоим. А теперь тебе отдельная задачка - победить скринкапчеров Думай. У меня решение есть, да. Но ты подумай сам.
Генерировать уникальный ссылки для конкретного пользователя. Т.е. залогинился вася, для него уникальная ссылка, так пусть он его тысячам передаст толку ноль. А если еще @Fell-x27 поделится с тобой инфой как победить скринкапчеров то думаю будет вообще гут). В вообще, я думаю, это не сильно будет спасать. Тот же Вася, который оплатил за видео-уроки, может скачивать их и использовать в коммерческих целях, или же просто делиться с друзьями). --- Добавлено --- @Fell-x27, я вот думаю, как победить скринкапчеров, ничего лучше как на видос ставить "свой" водяной знак, не придумал. Так хотя бы какая-то польза, пиар))
Это никак не защитит от скачивания Васей и выкладывания в свободный доступ. У меня не может. По одной ссылке можно сделать только один range-запрос.Ссылку можно перехватить только после того, как она была использована. Технически, конечно, можно поставить брейкпоинт в нужном месте и перехватить ссылку до. Но тогда вывалишься из "окна ожидания" и сервер поймет, что дело не чисто. Направление верное. Но лишь на 90%. Свой водяной знак не защитит от выкладывания в массы. А вот водяной знак с личными данными пользователя, который смотрит видео, с платежными реквизитами, почтой, номером телефона - защитят.
Ну так там тот же самый браузер, если видосик показывается в хроме, точно так же он отловится и там. А дальше джаваскрипт в руки и вперед ловить-передавать-сохранять.
Кэша нет. Видосик грузится чанками. Каждый чанк по своей ссылке, которую надо запросить. Весь код подгружается не в файлах, а так, что сразу оказывается закрыт внутри виртуальной машины, без возможности переписывания на лету. Важные объекты зафрижены, чтобы не правились через консоль. Ну и да, чтобы что-то написать, надо начать дебажить. Сервер знает, как ведет себя клиент в нормальных условиях. Поведение под дебагом несколько отличается. Блокировка. Следующая попытка поставить брейкпоинт будет стоить столько же, сколько и прежняя - стоимость купленного курса. Но только через N месяцев, когда поток доучится и откроется набор на новый. Повторюсь еще раз - что-то стопроцентно защитить нереально. Ты уже доставил контент пользователю. Все. И заказчик мой тоже знает это. И обсуждали с ним это. Прекрасно все понимает. И его позиция "если это отвадит хотя бы казуалов, качающих через расширения для браузера, это уже прекрасно". Запретить забрать контент кому-то "технически подкованному" нельзя. Но можно максимально испортить ему жизнь, усложнив процесс, сделав его невыгодным.
Не, посыл верный, не спорю. Думаю я бы смог добраться до видео, но сильно сомневаюсь, что при этом не нарвусь на одну из блокировок ) Особенно, если заранее такого не ожидаешь и есть только одна попытка. Ну к примеру вот https://www.npmjs.com/package/nightmare-webrequest-addon, я ведь могу перехватить эти чанки и сохранить себе. Останется только собрать потом из них видосик. Какой капкан меня поджидает в этот момент? ) /я ща чисто теоретически, на практике как-то не доводилось это юзать/
Это уже тебя не защитит в части распространения чужих персональных данных. И опять же не защитит от распространения никак.
@Fell-x27 большое спасибо, что не ленишься писать статьи. Очень много полезного. По поводу динамических ссылок - не работал с таким раньше (да и много с чем описанным не работал, но тем интереснее будет ). Это какой-то модуль апача?
Ну тут как. В соглашении, которое аппрувит пользователь, сказано, что материалы только для личного пользования. И видосик с его личными данными будет доступен лишь только ему одному. Если пользователь решил сграббить и выложить это все - это дело пользователя. Это все равно, что отсканить паспорт, выложить на imgur, а потом обвинять imgur в распространении личных данных пользователя. На деле, это больше психологическая мера, да, она ничего не гарантирует. Лишь снижает вероятность. Заказчик, опять же, прекрасно осведомлен обо всем этом. Это модули мозгача, и прямача-рукача
Все это понятно но дядя вася чьи платежные и прочие данные в итоге будут на утекшем в инет видео нагнет твоего заказчика в любом суде при желании. По остальным решениям - ок, вполне себе.
Ну как минимум все тот же - у тебя всего одна попытка, чтобы все сделать правильно. Ну а глубже - надо почитать про инструмент подробнее.
А вот не факт. Ты слил мой урок в интернеты и я Везде расклею твое лицо потому что оно в плательщике указано?
Со стороны сервиса, технически, только такой вариант возможен. Все остальное - на совести Дяди Васи. Тут те же риски нарваться на иск, что, скажем, у интернет-банкинга, сидя в котором Дядя Вася понаделал скриншотов со своими данными и выложил в сеть.
Ок, ты оставил неразлогиненым свой интернет-банк, я подошел, записал видео, где засветились твои данные и слил его. Виноват, стало быть, интернет-банк? Это интернет-банк закон нарушил или ты обосрался с доступом к аккаунту? --- Добавлено --- А так - чисто технически не заложена возможность администратору, например, посмотреть видео с чужой конфиденциальной инфой, чтобы что-то такое провернуть. А на уровне хранения данных я подумываю прикрутить шифрование в будущем, чтобы даже в БД все лежало в закрытом виде. Но надо подумать, как сделать так, чтобы ключ был только у пользователя. Пока что на ум приходит вариант шифрования по паролю. Но тогда ж его надо хранить где-то в системе хотя бы на время сеанса, в открытом виде. А это некрасиво. А если юзать хэши от каких-то данных, то смысл шифровать, если ключ под носом?..
Да, @TeslaFeo, если будешь отдавать видеопоток через PHP, не забудь отключить буферизацию вывода в этом коде, если она включена. Удивишься, как легко и непринужденно PHP валится в FatalError по превышению памяти, когда пытается слить крупный пакет данных не в поток сервера, а в собственный буфер. Ну и отдавай серверу маленькими порциями, а не по принципу "открыл и пошел до конца". Избежишь многих проблем разом. И, если работаешь через апач, обязательно накати nginx поверх. В данной задаче это - критически важный момент. Нельзя позволять папачу висеть на коннекте, сбрасывая данные клиенту и уповая на его широкий канал. Сервер кончится быстрее, чем успеешь подумать "а что может случиться?" Клиент может читать поток данных в реальном времени. То бишь, кусок файла, отвечающий за 3 минуты видео клиент запросто может читать 3 минуты к ряду. Зависит от того, будет ли клиент буферить данные или не будет. Разрешать папачу 3 минуты висеть на коннекте - это угар, форков не напасешься. Пусть этим nginx занимается. А дело папача - сбросить ему данные со скоростью, какую винт выжать сможет, и успокоиться.
помоему ты загоняешься. Речь не об интернет банке шла. А о "пап я оплачу урок пыхыпе с твоей карты?" Потом он его выложит, данные папа-юриста засветятся в тырнетах, но дело хозяйское конечно . Вообще бы так не морочился с этим, это всё паук из костылей.
Тоже есть такая мысль. И сынуля получит пиздюлей. Но я понял тебя. Вынесу это на повестку. Но да: 1) У нас там цены не 200 рублей у бати взять, а по 15-20килорублей за курс. Есть вероятность, что сынуля получит пиздюлей уже на этапе получения батей смски от банка. 2) Оплата доступна только после зачисления на курс, а не до. Так как имеет место конкурс. 3) Лица до 18 лет либо не принимаются вовсе, либо только после разговора с родителями уже сейчас. Как раз в силу пункта 1.
@tesla, вот те свеженький головнячок: 1) MediaObject в FireFox не умеет работать с Range-ответами и, запросив [0-*], ждет файл целиком, в то время как Хром и Сафари достаточно умные, чтобы, приняв кусок файла с 206 статусом, попросить новый кусок, когда будет нужно. 2) Выходом может являться использование собственной логики работы с буферами данных через MediaSource. Это охренительная тема, дико развязывающая руки. 3) MediaSource не поддерживается на iOS. Ни в Safari ни в Chrome. При этом в MacOS все работает (сука!). В итоге: 1) Либо мы посылаем нахрен iOS и делаем вообще что хотим на MediaSource. 2) Либо мы посылаем нахрен FireFox и просто работаем с Range. 3) Либо мы никого не посылаем, но на iOS придется городить костыли на Range, на Chrome у нас будет царский MediaSource, а FireFox-у будем отдавать файл целиком. Уповая на то, что аудитория, пользующаяся им, будет крайне мала и не вынесет нам сервер.