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





Защищать контент довольно просто: просто напишите страницу, которая имеет доступ к данным сеанса / безопасности пользователя, и проверьте, имеют ли они право загружать запрошенный файл. Вы можете легко сделать это с помощью сервлета Java или любой другой веб-платформы, такой как ASP.NET, PHP и т. д.
Я бы не рекомендовал эту технику использования нескольких паролей. Это будет проблемой для ваших клиентов. Это также создает впечатление, будто ваши клиенты пытаются обмануть систему. Вместо этого я бы записал все входы пользователей в систему, а также доступ пользователей к определенному файлу, а также регистрировал IP-адреса. Вы можете написать код для анализа этих данных и поиска одновременных входов в систему с разных IP-адресов. Вы также можете написать код для предотвращения множественных входов в систему.
Вы мало что можете сделать, чтобы люди не копировали ваш контент. Если вы хотите, чтобы они могли его просмотреть, им нужно будет загрузить его. Если они могут его скачать, они могут его сохранить.
Я не хочу, чтобы это выглядело безнадежным, но я просто пытаюсь быть честным здесь. Вы можете попытаться определить, не запускал ли кто-то в своей учетной записи паука на вашем сайте, хотя это может быть немного сложно. Можно ограничить их загрузкой 1 страницы каждые 10 или 15 секунд. И ограничьте его до 50 страниц на один логин. Это было бы не слишком заметно для большинства пользователей, но сильно сдерживало бы любое автоматическое сканирование, которое пользователь пытался сделать. Эти числа, возможно, потребуется изменить в зависимости от типа контента, который вы размещаете.
ПРИМЕЧАНИЕ. Оглядываясь назад, я вижу много недостающих деталей и крайних случаев, которые нужно идентифицировать. Я оставляю его в этой форме, потому что считаю полезным передать его смысл (даже если детали не совсем полностью сформированы), чтобы вы могли увидеть, что вас ждет. Вам нужно будет проработать модель угроз, чтобы дела выстроились должным образом.
Что касается паролей, вы можете предотвратить совместное использование паролей с помощью процесса аутентификации, который использует безопасное соединение (TSL и https :) и который на стороне клиента вычисляет хэш введенного пользователем пароля вместе с машиной и учетной записью пользователя ( идентификатор пользователя с вами и учетная запись пользователя на клиентском компьютере) связанные данные. Даже если пароль станет известен, функция хеширования не создаст правильный хеш на другом компьютере или другой учетной записи.
Есть интересная проблема, как хэш (который вы принимаете - вы никогда не знаете пароль, выбранный пользователем) устанавливается в первый раз для ассоциации с идентификатором пользователя, используемым с вами. Вам понадобится что-то вроде уникального ключа, предоставленного для подписки и предоставленного посредством рукопожатия по электронной почте во время регистрации и первоначального выбора идентификатора пользователя (если он отличается от адреса электронной почты) и пароля.
Если вы используете файлы cookie, чтобы людям не приходилось повторно входить в систему, вы можете захотеть иметь зашифрованную / хешированную информацию в файле cookie, который связывает его с машиной, а также с подпиской.
Теперь, сделав так много, у вас действительно есть проблема людей, которые хотят иметь возможность работать с нескольких компьютеров, а также им необходимо сбросить пароль пользователя, чтобы они могли выбрать новый вместо забытого / взломанного. Поскольку это означает предоставление поддержки по телефону и другие средства повторной проверки подлинного пользователя, вы можете подумать, стоит ли это затрат для вас и будут ли пользователи сочтены, что это стоит затрат для них.
Что касается незаконного присвоения материалов, полученных с сайта, у вас гораздо сложнее. Шифрование не очень поможет, и вы часто хотите разрешить пользователям сохранять материал для автономного использования, ссылки во время работы с материалом и т. д. Что вы можете сделать, так это идентифицировать материал как свою собственность, а также идентифицировать материал как свою собственность и как предоставлено конкретному подписчику способами, при которых трудно исключить все случаи возникновения. Это большая работа на стороне сервера. В сочетании с очевидной демонстрацией недоверия к подписчикам вы, возможно, захотите пересмотреть свое мнение и поработать, чтобы получить что-то более надежное и, скажем, предоставляющее что-то ценное, что не отражается просто в наличии контента. Вы уверены, что хотите это сделать?
ПРИМЕЧАНИЕ 2: Если вы продвигаете какой-то прогресс, например, прорабатываете учебные программы и уроки, есть очевидные вещи, которые вы можете сделать, чтобы, если каким-то образом придет несколько человек, если они добьются какого-либо прогресса, они все испортят. для всех остальных. Чем больше персонализации и прогресса, тем менее привлекательно предоставлять учетную запись кому-то другому. Это не препятствует сохранению материала, но любое повсеместное повторное использование извлеченного контента необходимо решать другими способами.
Даже при наличии поддержки попытка привязать пользователя к определенной машине - проблема. Озабоченные пользователи не будут в восторге от оплаты.
Я согласен. Я думаю, что лучше использовать слабую, но легко поддерживаемую аутентификацию и, возможно, некоторую персонализацию доставляемого контента. Все остальное следует приберечь на тот случай, когда проблема действительно обнаруживается и явно причиняет вред.
Никогда не беспокойте своих клиентов. Всегда есть способы получить контент без проблем, и большинство из них будут означать, что вы не видите денег.