Два ключа в одной сети

Страницы: 1 2 След.
RSS
Два ключа в одной сети
 
Два ключа HASP HL Net с разным набором Feature, ПО настроено таким образом что в зависимости от включенных Features изменяется функционал. И при  наличии двух ключей происходит безобразие.. по работает не так как нужно.. Как заставить одну копию ПО работать только с определенным ключем, а другую с другим.. если разработчиком ПО в настройках таких опций не предусмотрено.  
 
Добрый день.

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

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

Есть ещё вариант, когда разработчик ПО защищал своё решение через Envelope, и либо у него ПО написано на .NET или Java, либо это множество разных dll/exe файлов, в таком случае единственным возможным вариантом тут (если не использовать API) - это в настройках Envelope жёстко задавать Key ID ключа, к которому будет привязан данный защищаемый экземпляр ПО, и для каждого ключа собирать(защищать) свой дистрибутив ПО.
Подобный вариант очень неудобен как с точки зрения лицензирования, так и с точки зрения защиты, поэтому настоятельно рекомендуем использовать вариант лицензирования через API, а сверху такое приложение защищать утилитой Envelope - так будет наиболее гибко и правильно с точки зрения защиты и лицензирования.
 
Спасибо
 
> тоже разнесите их на два разных ПК

угу, а потом

> изолировать их друг от друга посредством (рррр!) настроек в менеджере лицензий

Есть ещё один "дедовский" способ - netHasp.ini рядом с каждым exe-шником

Точнее этот файл давно не используется, но насколько я помню начиная с 7.60 придумали какой-то другой файл настроек, который рядом с программой мoжно класть
 
Цитата
Yury Goryachev пишет:
в настройках Envelope жёстко задавать Key ID
Цитата
Yury Goryachev пишет:
очень неудобен как с точки зрения лицензирования, так и с точки зрения защиты
с точки хрения защиты внутрених утилит - это как раз очень удобно.
есть два ключа, рабочий в серверной и резервный у Самого Главного Начальника.
все настройки утилиты хранятся в ключе
При доработке утилиты - делается и выкладывается два EXE-шника

А вот для лицензирования "наружу", для пользователей - это да, будет очень сложно.
ОСобенно в случае SL-ключей
 
Дмитрий, не путайте человека!
Цитата
Дмитрий Буров пишет:
netHasp.ini рядом с каждым exe-шником
Это было актуально только для систем защиты HASP4 / HASP HL и уже более 10 лет как не используется.
Цитата
Дмитрий Буров пишет:
но насколько я помню начиная с 7.60 придумали какой-то другой файл настроек, который рядом с программой мoжно класть
Файл hasp_vendorId.ini с подобными настройками, подробнее тут:

http://sentinelldk.safenet-inc.com/LDKdocs/SPNL/LDK_SLnP_Guide/Distributing/License_Manager­/070-Working_directly_with_Config_Files.htm
 
Ага, спасибо за ссылку.

> serveraddr     Append specific machines that may be searched by the current machine for remote Sentinel License Managers.

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

Кстати, возможно в этот файл было бы хорошо ввести опциональные параметры белого и черного списка Hasp ID, возможно как XML scope

Но если разработчик ПО в него встраивал модули защиты (OBJ, DLL, etc) от более ранних, чем 7.50 то это проигнорируется и ничего тут не сделать, какую бы не ставит ьверсию рантайма, так? Я думал это от версии рантайма зависит, ищутся эти файлы или игнорируются.


И тут еще вопрос.  Допустим, у меня два сервера и два ключа - A и Б ( по одному на сервер ).
На сервере А запускаем программу ,которая ищет ключ Б. Т.е. рантайм на А соединяется с рантаймом Б и кэширует наличие ключа там.

Теперь на третьей машине мы запускаем программу, которая может подключаться к серверу А, но не Б (как вы и описали, ограничения на доступ по TCP/IP).
Эта третья машина ведь всё равно увидит ключ Б, через проксирование рантаймом на А, так ведь?

В отличие от HASP4 где аналогичный пункт ini жестко запрещал рассматривать любые ключи с непрописанных серверов - тут это все равно будет разрещено, просто с меньшим приоритетом.
 
Дмитрий,
Цитата
Дмитрий Буров пишет:
Т.е. он все равно будет искать на других серверах тоже, указанные явн осервера будет первыми в поиске, но не последними (если не отключить броадкаст), так ?
Так.
Цитата
Дмитрий Буров пишет:
так? Я думал это от версии рантайма зависит, ищутся эти файлы или игнорируются.
Это зависит именно от версии используемого API.
Цитата
Дмитрий Буров пишет:
Эта третья машина ведь всё равно увидит ключ Б, через проксирование рантаймом на А, так ведь?
Если у Вас на ПК в настройках АСС или в ini файле настройки заданы таким образом чтобы брать лицензии только с определённых ПК, то он и будет брать лицензии только с этих ПК, именно из локально подключенных там ключей. Сетевой ключ он не должен воспринять...но лично, я этого не проверял, так что 100% гарантии дать не могу. =(
 
Цитата
Yury Goryachev пишет:
или в ini файле настройки заданы таким образом чтобы брать лицензии только с определённых ПК
в hasp_vendorId.ini согласно документации по вашей ссылке таких настроек просто нету.

а общая логика ваших рантаймов сейчас - создание единого p2p облака, в котором все ключи общие.

Поэтому насколько мне кажется (я тоже не проверял):

1. настроить в ACC (через GUI или через его ini) можно черные и белые списки серверов, но это не относится к пожеланию топикстартера: такие настрйки будут глобальны, а он хотел на одной машине запускать программы с разными настройками

2. настроить это с помощью рядом с EXE положенным локальным hasp_vendorId.ini невозможно (либо недокументировано)

3. поскольку топикстартер не знает и не контролирует какую версию API поставщик ПО кладет внутрь своей программы, то у него вобще нет никаких гарантий, что hasp_vendorId.ini будет программами учитываться
 
Дмитрий,
Цитата
Дмитрий Буров пишет:
в hasp_vendorId.ini согласно документации по вашей ссылке таких настроек просто нету.
Запрещаете Broadcast и указываете только конкретные ПК, я это имел в виду.


Цитата
Дмитрий Буров пишет:
а он хотел на одной машине запускать программы с разными настройками
Тут я уже писал ему, что решение предпочтительное - реализация подобного механизма при лицензировании через API, тем более что это наиболее гибкий механизм, как ни крути.

Цитата
Дмитрий Буров пишет:
настроить это с помощью рядом с EXE положенным локальным hasp_vendorId.ini невозможно (либо недокументировано)
А с этим никто и не спорит. Хотите гибких настроек - используйте API.

Цитата
Дмитрий Буров пишет:
поскольку топикстартер не знает и не контролирует какую версию API поставщик ПО кладет внутрь своей программы, то у него вобще нет никаких гарантий, что hasp_vendorId.ini будет программами учитываться
А кто сказал что вопрос задаёт именно EndUser? =) Если глянуть ещё один топик от этого же пользователя с форума, то видно, что раз он спрашивает как писать в RO память ключа, то вероятнее это именно разработчик, а следовательно ему-то точно известно чем и как они защищают своё ПО.
Страницы: 1 2 След.
Читают тему (гостей: 1)