Долго думали втроём, но так и не пришли к решению следующей проблемы:
Есть CMS. Необходимо реализовать систему лицензионных ключей / обновлений системы. Должно быть так: человек покупает систему и получает от нас лицензионный ключ на одну копию системы. тот ключ используется при загрузке обновлений системы. Проблема стоит вот в чём: как остледить, используется ли этот ключ только на одном сайте или на нескольких? Может человек установил себе вторую копию системы на поддомен и хочет нахаляву загружать обновления. Соединение с сервером обновлений будет осуществляться, как мы решили, по сокетам, куда будут писаться необходимые данные, а в ответ получать обновления.

Есть у кого мысли?

После обновления системы старый ключ удалять и выдавать новый.
Т.о. по старому ключу обновиться больше не удастся.
Заодно пользователи будут заинтересованы в нераспространении своего ключа. Иначе они потеряют возможность обновляться.
Это только в самых общих чертах и для однопользовательской копии программы.

Спасибо, мысль достаточно интересная, надо подумать.

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

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

На одном IP может быть дофига сайтов. Может просто проZendить всё это и не париться?

Вариант первый - обфускация кода.
Вариант второй - открытое ПО с donate системой, как мне кажется больше получишь.
Вариант третий - с ключами. НО ключ привязывается к каким лмбо персональным данным, которые люди не желательно будут распространять. К примеру фамилия. При это варианте все равно будет работать варежная система для своих.

А чем твой первый вариант мешает использованию системы на другом сайте???

Если в conf.php будет какая-ть конфигарция привязывающая скрипт к одному серверу, то запустить его на другом - проблематично.

Mal Hack, Вариант с персональными данными очень понравился. А donate-система это как?

Это как mozilla.org. За ПО не платишь, а если хочешь спонсируешь по мере сил и возможностей.

IonCube и система лицензий. Каждому клиенту генерируется лицензия с привязкой к домену или IP (лучше к тому и другому). В лицензию так же можно добавить переменные (например список модулей, которые можно обновлять).

Поподробней, пожалуйста.

Да, мне тоже интересно.

Добавлено @ 02:46 
Как я понял, IonCube - такой шифровальщик. А чем ZendEncoder не устраивает? Ведь он более распространён на хостингах.

Да ничего бороть не надо.
Если дело конечно только в обновлении.
После установки генерируется ключ. Абсолютно любой. И регистрируется в системе обновлений.
При обновлении система проверяет ключ и если он совпадает выдает новое обновление. После чего генерирует новый ключ. Передает его копии программы и регистрирует у себя.

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

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

Это я понял. Но вопрос стоит в другом: пользователь посмотрел, в какой таблице хранятся обновления и написал скриптик, достающий оттуда код. Потом он сделал ещё 1 (2, 3.... 10000) сайтов на системе и исправил код в системе таким образом, чтобы ключ брался из одной базы и ложился после обновления туда же. Т.е. 10000 сатов будут пользоваться одной базой для хранения лицензионного ключа. Значит он всегда будет там самый свежий и любая копия системы сможет запросто обновиться. 

Crone, 
ИМХО:
Исходники кодируешь Зендом (Что бы не могли править исходники, ибо нефиг). Далее при первом запуске системы генерируется ключ, например:

На основе этого ключа вы генерируете серийник и выдаете юзеру.
Далее при обновлении смотрите к какому ключу принадлежит серийник, если не совпадает - порите ремнем  все ок - выдавайте обновления. При попытке обновления естественно нужно проверять как серийник так и ключ.
Если кто то попробует передать серийник - никаких проблем.

Ключи и серийник хранить не в базе, а в пхп файле (Зазенденном )) ), т.е ещё фиг ключ получишь просто так. 

Хм. А есть возможность Зендить файл прямо из PHP? Т.е. чтобы сгенерировать ключ и серийник и зазендить их сразу.

Добавлено @ 15:07 
Хотя, врпинципе, это и не нужно - просто файл генерировать вручную и через ту же систему обновлений высылать потом пользователю.

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

Надо обдумать все предложенные варианты. Думаю, что завтра сделаю пост о том, что же я рассчитываю сделать, а вы прокомментируете моё решение.

IonCube гораздо дешевле. + дает возможности как лицензирования, так и шифрования/дешифрования файлов.
На западных хостингах IonCube доступен практически везде -- или установлен как расширение пыха или можно загрузить его самому функцией dl()
На русских хостингах он менее распространен, но на многих все же доступен одним из способов.
Тем более для такого проекта все равно будет (должен) использоваться свой выделенный сервер, следовательно в установке энкодера проблемы не будет.

Описание возможностей енкодера тут: Stand Alone ionCube PHP Encoder

Логику я представляю себе следующим образом:

1. Клиент получает заенкоденный программный продукт
2. Клиент получает лицензию (привязанную по IP и имени хоста к сайту), причем ограниченную по-сроку например годом
3. В лицензии для каждого клиента хранится переменная с некой хеш-строкой. Эта же строка лежит в базе на сервере.
4. Для запроса на обновление клиент генерирует запрос (например в виде XML) и шифрует его внутренней функцией API енкодера, используя хеш-строку (ключ) из лицензии
5. Сервер "видя" откуда пришел запрос, берет из базы ключ и пытается расшифровать с его помощью этот запрос
6. Если ключи совпали -- значит дешифровка удастся и запрос пришел верный. Можно апдейтить.
7. Если ключи не совпали -- значит кто-то пытается перехетрить систему. Но такого варианта не может быть потому что если ключ на стороне клиента будет браться из лицензии -- его изменить нельзя: нарушится целостность файла лицензии и продукт совсем работать не станет.

Саму процедуру апдейта я предлагать не буду -- все от софта зависит. Но ИМХО предложенный мной вариант гарантирует лицензионность обновлений и то, что одна инсталяция системы используется только на одном сайте единовременно.

Знаете, что я подумал... Просто сделать интерфейс для обновления на сайте разработчиков. Т.е. создать отдельный раздел и в него давать доступ по лицензионному ключу. Потом пользователь выбирает обновления и система загружает их ему на сайт сама по FTP. Разумеется, там в базе будут хранится данные от хостинга - это будет обязательным условием при покупке системы, чтобы мы могли смотреть, установлена одна или 10 копий системы на сервер и для загрузки обновлений. Как вам идея?

Добавлено @ 22:36 
Разумеется, пользователи смогут слить систему по FTP и залить на другой сайт и там установить, но я не думаю, что много кому в голову прийдёт заниматься таким геммороем.

Если в таком случае системой можно будет пользоваться "забесплатно" -- прийдет в голову однозначно. Да и код поправить всегда смогут если нужно.

Crone, наиболее надежная из всех предложенных систем выдачи обновлений признаю метод G0rinich. Мы сделали практически аналогичный процесс для обновлений CMS клиентов. Безусловно, база обновлений, хранение ключей и проверка IP адресов и др. данных должны быть расположена на сайте фирмы-разработчика (фирмы-поддержки), даже при условии, что код будет зазенден. Также необходимо, как уже бело подмечено, периодически менять лицензионные ключи, может быть не при каждом получении обновлений, но достаточно часто с определенным периодом.
  Если будут какие-то дальнейшие соображения, в том числе реализация определенных моментов процесса обновления - буду рад пообщаться и "махнуться" опытом.   

Идея G0rinich'а самая надежная. Только имеет смысл сделать так, чтобы новый ключ содержал инфу о версии загруженного обновления и позволял загрузить только более новую версию

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

ну чтот такого...

обновление будет идти через сайт клиента копиие продукта ? если да : 

1 увас есть бд собственная ключей где записаны все ключи продуктов структура 

ID | DATE_ACTIVATION | KEY | SITE | TYPE_LECENCE

DATE_ACTIVATION Дата активации 
KEY - уникальный ключ
SITE - адресс сайта
TYPE_LECENCE тип лецензии (на 1 год, 2, 3 итд.)

2 если пользователь нажал обновление

отсылается ключ проверяем его по БД смотрим дату активации проверяем откуда пришел запрос с какого сайта если совпадает с сайтом в БД и колючем.

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

все действия делать через сокеты. можно еше временную сессию прикрутить скажем на 1 час.

Сори если повторил кого то. Я не полностью все посты прочитал только некоторых людей.

Если сольют сайт, нелегальное использование ПО карается законом если докозуемо. 

Вы как сделайте. Для каждого пользователя свой ключ. В ключе (как уже было предложено) хранить какие-то пользовательские данные. После выдачи ключа, купившему надо зайти в админку и активировать этот ключ. Он заходит, вводит ключ, вы его проверяете и вносите себе в базу. И если кто-то еще раз попытается использовать тот-же ключ, то просто посылать его за покупаками. 
Если все норм, то в корне сайта создать файл (ток зашифровать его потом =)) с ключем и уникальной для этого сайта строкой (например путь:
для каждого сайта он будет различаться /home/server/exxample.com/www, тобиш я имею ввиду, что шанс совпадения маловероятен.)
В index.php проверять все это и опять же либо отсылать за покупками, либо пусть работает. 

З.Ы. тему не читал, ссори, если уже есть такое предложение

Alex13, сорри, промазал когда жал.


Djinn, это относится к тебе: