Подписка защищает контент?

1. Защитить контент довольно просто: просто напишите страницу, которая имеет доступ к сведениям о сеансе/безопасности пользователя, и проверьте, авторизованы ли они для загрузки запрошенного файла. Вы можете легко сделать это с помощью сервлета Java или любой другой веб-платформы, такой как ASP.NET, PHP и т. д.

2. Я бы рекомендовал против этой техники нескольких паролей. Это будет проблемой для ваших клиентов. Это также создает впечатление, что вы предполагаете, что ваши клиенты пытаются обмануть систему. Вместо этого я бы регистрировал все входы пользователей в систему, а также доступ пользователей к определенному файлу, а также регистрировал IP-адреса. Вы можете написать код для анализа этих данных и поиска одновременных входов с разных IP-адресов. Вы также можете написать код для предотвращения множественных входов в систему.

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

Я не хочу, чтобы это казалось безнадежным, но я просто пытаюсь быть честным здесь. Вы можете попытаться определить, запускал ли кто-то паук вашего сайта в своей учетной записи, хотя это может быть немного сложно. Может быть, ограничить их загрузкой 1 страницы каждые 10 или 15 секунд. И ограничьте его до 50 страниц на вход. Это не было бы слишком заметно для большинства пользователей, но серьезно сдержало бы любой автоматический поиск пауков, который пытался выполнить пользователь. Эти цифры, возможно, придется скорректировать в зависимости от типа контента, который вы размещаете.

ПРИМЕЧАНИЕ. Оглядываясь назад, я вижу много недостающих деталей и крайних случаев, которые нужно определить. Я оставляю его в таком виде, потому что считаю полезным передать его смысл (даже несмотря на то, что детали не совсем сформированы), чтобы вы могли увидеть, что вам предстоит. Вам нужно будет проработать модель угроз, чтобы правильно выстроить случаи.

Что касается паролей, вы можете предотвратить совместное использование паролей, используя процесс аутентификации, который использует безопасное соединение (TSL и https:), и который на стороне клиента вычисляет хэш введенного пользователем пароля вместе с машиной и учетной записью пользователя ( идентификатор пользователя с вами и учетная запись пользователя на клиентском компьютере), связанные данные. Даже если пароль станет известен, функция хеширования не создаст правильный хэш на другой машине или учетной записи пользователя.

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

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

Теперь, проделав так много, у вас действительно есть проблема людей, желающих иметь возможность работать с нескольких компьютеров, а также необходимость сбросить пароль пользователя, чтобы они могли выбрать новый вместо забытого/скомпрометированного. Поскольку это означает предоставление поддержки по телефону и другие средства повторной проверки подлинности пользователя, вы можете подумать, стоит ли это затрат для вас и сочтут ли пользователи это оправданным для себя.

Что касается незаконного присвоения материалов, полученных с сайта, то у вас проблема гораздо сложнее. Шифрование мало чем поможет, и вы часто хотите разрешить пользователям сохранять материал для автономного использования, ссылки во время работы с материалом и т. д. Что вы можете сделать, так это идентифицировать материал как вашу собственность, а также идентифицировать материал как вашу собственность и как предоставляется конкретному подписчику таким образом, что трудно исключить все вхождения. Это большая работа на стороне сервера. В сочетании с очевидной демонстрацией недоверия к вашим подписчикам вы можете пересмотреть свое решение и поработать над тем, чтобы иметь что-то более надежное и, скажем, предоставлять что-то ценное, что не отражается только в наличии контента. Вы уверены, что хотите это сделать?

ПРИМЕЧАНИЕ 2. Если вы обеспечиваете какой-то прогресс, например, работаете с курсами и уроками, есть очевидные вещи, которые вы можете сделать, чтобы, если каким-то образом придут несколько человек, если они добьются какого-либо прогресса, они все испортят. для кого-либо еще. Чем больше персонализации и развития, тем менее привлекательно предоставлять учетную запись кому-то еще для использования. Это не препятствует сохранению материала, но любое широкое повторное использование извлеченного контента должно решаться другими способами.