Подтверждение и отмена привязки лицензионного ключа?
Делаю php приложение. Пользователю выдаётся лицензионный ключ на использование приложения на несколько доменов (предположим 3, не суть важно). Проверка лицензии производится через http запросы.
С подтверждением лицензии проблем нет: при установке приложения делаю http запрос, проверяю ключ, если всё ОК, на принимающем сервере отмечаю, что осталось 2 установки.
При удалении приложения с домена, снова http запрос. На сервере отмечаю: осталось 3 установки. Подайте идею, как проверить, реально ли http запрос при деактивации пришёл из того же источника что и при активации, или он пришёл при ручных манипуляциях.
Пришла идея при активации записывать и IP, и потом проверять, пришёл ли http при деактивации из того же источника или нет. Но не уверен, что это 100% защита.
Дополнил.
Есть мысль, чтобы при активации отправлять какую-то автоматически генерируемую метку. А при деактивации производить http запрос с этой меткой. Вопрос в том, как хранить её так, чтобы пользователь не мог её узнать.
На несколько доменов или на несколько серверов?
Для одного домена у пользователя логично предвидеть как минимум две установки: на боевой сервер и на тестовый. IP тут несколько неуместен...
Ян Александров, я бы предложил не препятствовать установке вовсе, но в процессе запрашивать домен установки и отправлять информацию на ваш сервер, возвращая уникальный ключ для пары "лицензия - домен". И в рамках запроса обновлений проверять их. Если вдруг у кого-то из купивших многовато пар - пообщаться, что за дела.
Если установки идут косяком без лицензии вовсе - поздравляю, вы стали популярны ;)
В общем случае никак (в вашей схеме организации), так как ушлый пользователь может проксировать запросы к вашему серверу лицензий с любого количества установок.
Вы можете попробовать обусицифировать процесс установки и деинсталляции, привязывая ее к каким-нибудь внутренним идентификаторам системы, параметрам реестра и прочее прочее (в этом случае у вас будет по 1 запросу на установку и удаление), но опять таки ушлый пользователь может это отреверсить. системные вызовы отследить и симулировать одинаковые окружения, вам же объясняя что повторные активации - это у него винда слетела, диск помер и прочая лапша на уши.
Если бы вы могли развернуть технологию активации наоборот, когда ваш сервер лицензирования делает запросы к пользовательским машинам (для этого должен быть открыт доступ из вне к ним, либо через фаервол либо прокси) то тогда вы бы сами контролировали периодическими запросами на активацию (например 1 раз в сутки) и это нельзя было бы обойти (кроме как вообще взломать процесс проверки активации, что само собой запретить невозможно, но можно попытаться сделать этот процесс неоправданно дорогим).
Ян Александров, да вздор это все - защита по старинке в веб-приложениях. Это либо не работает вовсе, либо работает плохо и ваши же затраты на такую защиту будут больше, чем прибыль, а потенциальных клиентов вы ей отпугнете.
С веб-приложениями, имхо, работают только две схемы: армия юристов, которую вы не можете себе позволить, и завязка на получение обновлений, которые ваш сервер просто не отдает без подтверждения лицензии. Использование старых версий на халяву проще считать рекламной компанией, чем всерьез с этим бороться.
Adamos, keitarotds защищен ioncube и все у них шикарно работает. И защита, и обмен ключами, и файлы зашифрованы, и обновления я получаю каждый день практически. Судя по вопросу - автор разрабатывает что то подобное.
2vtlk, это закрытый полноценный зонд, который привязывает тебя к поставщику при любых изменениях на рынке, поскольку сам ты на них отреагировать не можешь. Собственно, схемы "плати, если хочешь обновлений" для этого случая достаточно. Ioncube тут имеет смысл разве что как защита от конкурентов, а не от покупателей.
Adamos, поставщиков много - никто же не мешает перейти к другому. Я давно пользуюсь таким ПО от разных поставщиков. Разрабатывать свой велосипед на масштабе 5 пользователей смысла не имеет :)
Средний
Средний
