Всем привет!

А вот подскажите, какие есть решения, когда контроль лицензий осуществляется централизованно (сервером) ?
А то решения типа ASProtect/Armadillo тут как-то не очень подходят — они ведь только один ключ в системе позволяют установить...

Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

Есть какие-то системы защиты, которые позволяли бы устанавливать несколько ключей в систему? Т.е. в данном примере — мы бы просто выслали ему еще один ключ на 50 лицензий и установив два в систему он бы получил свои 100 лицензий... Как-то эта схема мне правильнее кажется.


И еще один вопрос — а как тут быть в случае схемы лицензирования "по подписке" (годовой) — если получается что, скажем, первый ключ на 50 у него истекает в апреле, а второй купленный на 50 — в ноябре?

--
Regards,
Yuri Alexandrov

Здравствуйте, AYA, Вы писали:

AYA> ...

Посмотрите Starforce, меня он этим покупает.
Но, правда дороговато, и потом, про него на этом форуме мне никто так и не ответил.

Здравствуйте, AYA, Вы писали:

AYA>Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

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

AYA>Есть какие-то системы защиты, которые позволяли бы устанавливать несколько ключей в систему? Т.е. в данном примере — мы бы просто выслали ему еще один ключ на 50 лицензий и установив два в систему он бы получил свои 100 лицензий... Как-то эта схема мне правильнее кажется.

Такая система лицензирования пишется своими силами в течение 2-х дней (если конечно руки оттуда растут

Здравствуйте, AYA, Вы писали:

AYA>Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

Знакомая большая контора в этом случае требует с российского клиента гарантийное письмо — обязательство не использовать старый ключ. Решение чисто организационное, клиент просто попадёт на большие бабки, если нарушит. Не российских клиентов у них нет...

Здравствуйте, retalik, Вы писали:

R>Здравствуйте, AYA, Вы писали:

R>Знакомая большая контора в этом случае требует с российского клиента гарантийное письмо — обязательство не использовать старый ключ. Решение чисто организационное, клиент просто попадёт на большие бабки, если нарушит. Не российских клиентов у них нет...

Ну это не решение. Это так, страшилка. Бо как на практике задолбешься по судам что-то доказывать...

Здравствуйте, PolyTech, Вы писали:

PT>Здравствуйте, AYA, Вы писали:

AYA>>Есть какие-то системы защиты, которые позволяли бы устанавливать несколько ключей в систему? Т.е. в данном примере — мы бы просто выслали ему еще один ключ на 50 лицензий и установив два в систему он бы получил свои 100 лицензий... Как-то эта схема мне правильнее кажется.

PT>Такая система лицензирования пишется своими силами в течение 2-х дней (если конечно руки оттуда растут

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

Здравствуйте, AYA, Вы писали:

AYA>Ага, оно у программистов всё просто. А потом глючит или хакерами за пару дней отламывается...

Хакерами за пару дней отламывается как раз ASProtect/Armadillo

Здравствуйте, AYA, Вы писали:

AYA>Есть какие-то системы защиты, которые позволяли бы устанавливать несколько ключей в систему? Т.е. в данном примере — мы бы просто выслали ему еще один ключ на 50 лицензий и установив два в систему он бы получил свои 100 лицензий... Как-то эта схема мне правильнее кажется.

AYA>И еще один вопрос — а как тут быть в случае схемы лицензирования "по подписке" (годовой) — если получается что, скажем, первый ключ на 50 у него истекает в апреле, а второй купленный на 50 — в ноябре?

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


Можно сделать, чтоб сервер регистрировался по https на вашем сервере,
после чего получал все необходимые параметры для работы...

Здравствуйте, AYA, Вы писали:

AYA>А вот подскажите, какие есть решения, когда контроль лицензий осуществляется централизованно (сервером) ?
AYA>А то решения типа ASProtect/Armadillo тут как-то не очень подходят — они ведь только один ключ в системе позволяют установить...

AYA>Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

AYA>Есть какие-то системы защиты, которые позволяли бы устанавливать несколько ключей в систему? Т.е. в данном примере — мы бы просто выслали ему еще один ключ на 50 лицензий и установив два в систему он бы получил свои 100 лицензий... Как-то эта схема мне правильнее кажется.

Можно хранить несколько ключей. В ключ вшивается количество лицензий. При старте сервера, если первый ключ нормален, из него достаётся количество лицензий. Далее каждый ключ суётся в армадиллу, если тот говорит "ок", вытаскивается количество лицензий. Вводится следующий ключ. ОК? Количество лицензий из него суммируется к предыдущему. Последний ключ становится первым (чтоб на следующем запуске активировать все остальные кроме этого, который должен остаться активным). И всего делов. Руками надо будет только организовать хранилище этих ключей, добавление/удаление их из него силами администратора. Оно конечно нестандартный ход, но кто сказал, что нельзя активировать сертификаты на каждом старте приложения?
Это если я правильно понял задачу: вводим ключи — накапливаем мощь, выражаемую количеством лицензий; в каждом ключе хранится некоторое их количество.

Здравствуйте, PolyTech, Вы писали:

AYA>>Ага, оно у программистов всё просто. А потом глючит или хакерами за пару дней отламывается...

PT>Хакерами за пару дней отламывается как раз ASProtect/Armadillo

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

Здравствуйте, Xander Zerge, Вы писали:

XZ>Можно хранить несколько ключей. В ключ вшивается количество лицензий. При старте сервера, если первый ключ нормален, из него достаётся количество лицензий. Далее каждый ключ суётся в армадиллу, если тот говорит "ок", вытаскивается количество лицензий. Вводится следующий ключ. ОК? Количество лицензий из него суммируется к предыдущему. Последний ключ становится первым (чтоб на следующем запуске активировать все остальные кроме этого, который должен остаться активным). И всего делов. Руками надо будет только организовать хранилище этих ключей, добавление/удаление их из него силами администратора. Оно конечно нестандартный ход, но кто сказал, что нельзя активировать сертификаты на каждом старте приложения?
XZ>Это если я правильно понял задачу: вводим ключи — накапливаем мощь, выражаемую количеством лицензий; в каждом ключе хранится некоторое их количество.

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

Здравствуйте, AYA, Вы писали:

AYA>Я конечно понимаю что Вам очень надо свою защиту продать, но вот так бы оптом я бы на Вашем месте не хаял бы.

Вы всё не правильно понимаете. По ASProtect/Armadillo полно инструментов по полу и автоматическому снятию. Если в программе полагаться только на навесную защиту и полностью забить на реализацию внутренних механизмов, то такая защита долго не продержится.
Я как раз хотел донести до Вас то, что навесная защита играет чуть ли не последнюю роль. Специалисты даже с помощью UPX могут сделать очень серъезные вещи

AYA>Что-то они уже с весны как не могут отломать Armadillo с нашей программы. Ни одного рабочего кряка.

Я рад за Вас.

Здравствуйте, AYA, Вы писали:

AYA>А вот подскажите, какие есть решения, когда контроль лицензий осуществляется централизованно (сервером) ?
AYA>А то решения типа ASProtect/Armadillo тут как-то не очень подходят — они ведь только один ключ в системе позволяют установить...

У плимуса есть интегрированная система подобного типа, Piracy Protection by Plimus. Не пользовался, но на вид довольно простая. Если продукт предполагает сложную систему работу с клиентами (подписки, разные извратские ограничения функционала) возможно имеет смысл потратить время и разработать свою систему управления лицезиями

AYA>Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

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

Здравствуйте, AYA, Вы писали:


AYA>Простой пример. Есть система сервер-клиенты, контроль лицензирования идет на сервере. Купил клиент пакет на 50 лицензий, выслали ему ключ. Поработал он — и надумал что ему надо на 100 лицензий. Докупает еще один пакет на 50. Вопрос — как тут поступить? В случае с ASProtect/Armadillo — надо генерить новый ключ (на 100) и высылать. Но при этом он ведь сможет использовать предыдущий ключ на 50 лицензий на любом другом сервере! Нехорошо как-то...

Мы пользовались услугами вот этих ребят http://www.rainbow.msk.ru/

Работает так:

• В USB-ключ зашито кол-во лицензий.
  
• USD-ключ втыкается в сервер.
  
• Серверное приложение через КОМ-объект (предоставляется разработчиками) смотрит, сколько лицензий есть и разрешает/запрещает работу новых пользователей
  
• Если у вас купили "еще 50" лицензий — выдаете новый ключ.
  
• Два ключа в один сервер воткнуть нельзя.

Здравствуйте, zi, Вы писали:

zi>Работает так:
zi>

USD-ключ втыкается в сервер.
Это супер-ключ, открывает всё!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Xander Zerge, Вы писали:

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

Сергей скажите пожалуйста зачем переставлять последний ключь последним.
и почему количество лицанзий не учитываеться количество ключей — чтоб на следующем запуске активировать все остальные кроме этого

Помоему проще проверить все ключи и из валидных вытащить количество лицензий

Здравствуйте, <Аноним>, Вы писали:

А>Сергей скажите пожалуйста зачем переставлять последний ключь последним.
А>и почему количество лицанзий не учитываеться количество ключей — чтоб на следующем запуске активировать все остальные кроме этого

А>Помоему проще проверить все ключи и из валидных вытащить количество лицензий

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

Здравствуйте, AYA, Вы писали:

AYA>Всем привет!

AYA>А вот подскажите, какие есть решения, когда контроль лицензий осуществляется централизованно (сервером) ?
AYA>А то решения типа ASProtect/Armadillo тут как-то не очень подходят — они ведь только один ключ в системе позволяют установить...

Самописная система на Apache/https.
Клиент сообщает свой ключик в процессе работы (он это делает постоянно с интервалом в 10 минут) и получает ответ — можно ли работать дальше.
Серверная часть на PHP.
Банальный web-интерфейс позволяет редактировать емкость и тип лицензий, равно как и текст матюков которые показывает продукт при неудавшейся лицензионной проверке

Жутко примитивно ламать меньше 1 минуты
Потому что если связи с сервером нет то все должно работать — так в ТЗ указано.

Здравствуйте, Xander Zerge, Вы писали:

XZ>Здравствуйте, <Аноним>, Вы писали:

XZ>Заоптимизировался я. Просто учёл специфику армадилы. На активацию ключа там уходит какое-то время, полсекунды-секунда, поэтому можно экономить одну такую активацию, оставив

Большое спасибо за объяснение.