@nazarpc я тоже сначала подумал, что ключ и будет уникальной меткой: если две копии зареганы одним ключом - блок, а если заnullить продукт, тут и ключи не нужны, а значит и не вычислить утечку. Да и что помешает обnullить эту самую метку? Тогда опять встает вопрос о более глобальной системе учёта проданных ключей и копий продукта.
Отсюда три варианта:
1) Выносить ядро в облако (следовательно доп. затраты) и заморачиваться над секьюрностью взаимодействия API
2) SaaS и нагрузка на наши сервера или облако (следовательно доп. затраты) + API При DDoS-атаке накроются все пользователи (следовательно доп. затраты на услуги QRATOR или подобных компаний)
3) Кодировать (во-первых, можно раскодировать и обnullить; во-вторых, пользователь, который заплатил свои кровные лишается возможности перестроить систему "под себя", а многим это действительно необходимо)
Ну есть и еще вариант, забить на всю эту канитель и уйти в опенсорс ;)
К сожалению null-ятся многие продукты, не только CMS. Вот я и хочу подойти к этому вопросу более серьёзно. Про облако идея понравилась, достаточно вынести ядро, но опять же возрастёт время отклика продукта, плюсом встанет вопрос о секьюрности взаимодействия API.
Про шифрование тоже думали, но тогда нужен хостинг с поддержкой того же Зенда или Иона (хотя большинство площадок поддерживают и то, и другое).
Интересует именно практическая часть реализации, некий алгоритм, логика. Пока неясен сам алгоритм действий, не ясно как это организовать применив систему локально (не вынося функционал в облако, хотя, думаю, систему проверки выносить все равно придётся).
