Кyда пойдет Hasp_login при наличии SL И HL ключей ?

Поиск  Пользователи  Правила 
Страницы: 1 2 След.
RSS
Кyда пойдет Hasp_login при наличии SL И HL ключей ?
 
#1
28.05.2015 13:39:12
К вопросу о переходе с TrialWare на полнофункционал без переустановки
Поскольку обрезать функциональность не нужно (ограничение только по дате), то прошивка полноценого HL-ключа и пробного SL-ключа совпадает.

При этом будут возможны ситуации:
1) локальная версия, HL ключ вставляется в ту же машину, где и установленнаая рпограмма с provisional SL ключом
2) сетевая версия, HL ключ вставляется в сервер в той же сети, где и установленнаая пpограмма с provisional SL ключом

Вопрос, можно ли задать для hasp_login_scope приоритеты, типа "попробуй найти Hl-ключ, если не найдешь -тогда SL" и наоборот, типа "попробуй найти в сети, если не получится - то локально" и наоборот ?

Можно конечно делать несколько жестко-фильтрованных вызовов hasp_login, если первый не пройдет, то второй и т.д.. И в каждом разрешать только определенный тип ключа. Но нельзя ли поручить это рантайму? дать ему приоритеты поиска ключей, и путсь сам выберет более подходящий при одном вызове hasp_login_scope ?
 
 
 
#2
28.05.2015 15:20:27
Если scope в login не задан, в первую очередь подключается к ключу HL (не важно, локальному или сетевому).
Если этого ключа не обнаружено, либо все лицензии в нём выбраны, происходит подключение к ключу provisional SL.
 
 
 
#3
28.05.2015 17:25:55
Это поведение жестко зашито и не изменить через scope нельзя?

к любому SL или потому что он Provisional ?
 
 
 
#4
28.05.2015 18:41:36
Дмитрий, если Вы защищаетесь через API, то Вы вольны абсолютно как угодно и в удобном Вам порядке подключаться к ключам. Вы можете предварительно получить список доступных ключей с feature в них и дальше подключаться к любому из них, руководствуясь своей логикой.
 
 
 
#5
28.05.2015 18:57:05
Тоже вариант, да.

Просто всегда приятнее, когда за тебя другие работают. Типа сформировал запрос - и один вызов API все сделал :-D
 
 
 
#6
29.05.2015 09:02:03
Мой личный опыт показывает, что если ничего не указывать, то сперва происходит подключение к не provisional ключу (не важно, SL или HL, локальный или удалённый). Если полнофункциональный ключ не найден, или лицензии во всех доступных полнофункциональных ключах израсходованы, то в последнюю очередь происходит подключение к provisional ключу.
Повторяю, это, если не "диктовать" свою логику подключений.
 
 
 
#7
29.05.2015 13:14:53
спасибо
 
 
 
#8
09.08.2017 12:31:56
Откапываем стюардессу. Так получилось, что был проведен натурный эксперимент - использование SL-ключей в вирутальной машине HyperV2.

Были замечены два неожиданных эффекта.

Машина 1: виртуальная машина, с доступом по "нативному" протоколу Hyper-V. На ней был установлен SL-Admin ключ с сетевым доступом и проверена работа защищённой программы в "локальном" режиме, на той же VM. Сделали - и забыли.

Машина 2: другая виртуальная машина, на том же Hyper-V сервере, с доступом по RDP, на которой с защищённой программой работают регулярно, привязываясь по сети к HL-ключам (на других серверах).

С утра пользователь зовёт, программа перестала запускаться, ругается на невозможность работы под терминальным сервером. В ключе запрета на работу под RDP нет, вероятно этот запрет зашит в нашем коде поверх Runtime Licensing API. Ну либо у SL-Admin в виртуалке есть ограничение, что RDP запрещён что бы мы не писали в лицензии. Вряд ли, но возможно.

Код
<license_properties> <perpetual/> <concurrency><count>3</count> <count_criteria>Per Process</count_criteria> <network_access>Yes</network_access> <detachable>Yes</detachable> </concurrency> <remote_desktop_access>Yes</remote_desktop_access>        <virtual_machine_access>Yes</virtual_machine_access>        </license_properties>

Вижу в ACC на 2-й машине, что соединения к ключам уходят на виртуалку 1, понимаю что случилось. Т.е. действительно, у HL-ключа нет преимущества перед SL-ключами.

Было бы хорошо, если бы приоритет ключей можно было бы задавать внутри login scope.
В принципе - да, никто не мешает нам в нашем коде делать несколько попыток hasp_login с разными scope, пока один не сработает. Но это - в нашем. С Envelope так не получится. Там можно не больше чем задать scope, причём только один, а не несколько....

После того, как наша защита отстреливала программу по причине попытке запуска в терминальнике, в ACC оставалось висеть одно соединение к ключу. Т.е. ни Envelope ни Runtime не определял, что программа уже закрылась и не делала hasp_logout. Печально...

Открываю виртуалку 1, захожу в настройки ACC и запрещаю сетевой доступ к этому рантайму.
Открываю виртуалку 2, запускаю программу - та же диагностика. Смотрю в ACC - стандартные два логина в SL-ключ на 1-й виртуалке, от Envelope и от нашего кода.
Позволяю программе закрыться - одно из подключений остается висеть "призраком"....

То есть имеем интересный эффект - несмотря на запрет сетевого доступа к 1-му рантайму - он не только не отстрелил сессию, который 2-й рантайм держал на его ключ, но и позволял открывать новые сессии. Рантайм-2 присылала в рантайм-1 сетевой пакет "я тут у тебя залогинюсь", и рантайм-1 говорил рантайму-2 "вообще-то ко мне нельзя логиниться, но тебе - можно, и пофигу мне, что там юзер настроил".

После перезапуска службы рантайма-2 ситуация исправилась. В списке ключей в АСС 2-й виртуалки SL-ключ  с виртуалки 1 исчез, программа соединялась по сети с аппаратным HL-ключом и работала как обычно.
Но сам факт, что рантайм 2 пришлось перезапускать, чтобы заработали настройки рантайма-1...

Это напоминает сетевую безопасность в Windowf for workgroups, когдв сервер спрашивал клиента "а тебе точно можно писать-читать мои файлы", и клиент уже решал, должен сервер ему разрешать доступ или нет. C запретом "серверу" рантайм-1 отдавать "клиенту" рантайм-2 свои ключи в этом сценарии получилось именно так. Несмотря на запрет доступа сервер не только не разорвалсессию клиента, но и позволял делать новые логины.
 
 
 
#9
10.08.2017 11:27:13
Добрый день, Дмитрий.
Цитата
Дмитрий Буров пишет:
Т.е. действительно, у HL-ключа нет преимущества перед SL-ключами.
Приоритета и правда нет, но это никто и не скрывает. У нас аппаратные и программные ключи работают одинаково, отсюда и отсутствие подобного приоритета. Вы сами можете в своём ПО такой приоритет предусмотреть, когда защищаетесь через API.
Цитата
Дмитрий Буров пишет:
Было бы хорошо, если бы приоритет ключей можно было бы задавать внутри login scope.
Как раз это-то и можно сделать без каких-либо проблем - две попытки логина, первая на аппаратный ключ, если она проходит неудачно,то вторая на программный ключ. не вижу в это абсолютно никакой проблемы. Что касается защиты через Envelope - да, там нет возможности задавать именно приоритет, но повторюсь, это сделано из-за того, что в нашем решении нет различия между программными и аппаратными ключами - единообразие. И потом, как я понимаю в Вашем конкретном случае проблема не в том что нет приоритета, а в том, что Ваше ПО не было корректно настроено для работы с сетевыми ключами. В любом случае, никто не мешает Вам логику работы с ключами в своём приложении реализовывать через API, а механизмы защиты - через Envelope с защитой на Feature 0. Feature 0 есть во всех ключах и никак не ограничена, а всю схему работы с лицензиями в ключе Вы сами придумаете и реализуете через API - позволит Вам реализовать любой подход, какой заблагорассудится. По большому счёту многие именно так и делают, и это удобно.
Цитата
Дмитрий Буров пишет:
Т.е. ни Envelope ни Runtime не определял, что программа уже закрылась и не делала hasp_logout. Печально...
Сессия автоматически освобождается через некоторое время, обычно довольно быстро (речь о нескольких минутах: для сеанса с локальным ключом 3 минуты, для сеанса с сетевым ключом - 15 минут). Если же в директории с защищённым приложением есть файл hasp_rt.exe, тогда сессии должны уничтожаться немедленно.
Цитата
Дмитрий Буров пишет:
Рантайм-2 присылала в рантайм-1 сетевой пакет "я тут у тебя залогинюсь", и рантайм-1 говорил рантайму-2 "вообще-то ко мне нельзя логиниться, но тебе - можно, и пофигу мне, что там юзер настроил".
Дмитрий, настройку необходимо осуществлять через ini файл:
http://sentinelldk.safenet-inc.com/LDKdocs/SPNL/LDK_SLnP_Guide/Distributing/License_Manager­/070-Working_directly_with_Config_Files.htm
Цитата
Дмитрий Буров пишет:
Несмотря на запрет доступа сервер не только не разорвалсессию клиента, но и позволял делать новые логины.
Если бы он разорвал сессию был бы риск потери данных пользователя, с которыми он работает в защищённом приложении, и было бы больше недовольных таким поведением.
Перезапуск ПО, для применения некоторых из выставленых опций - вполне нормальная практика как мне кажется.
 
 
 
#10
10.08.2017 13:09:03
>> Было бы хорошо, если бы приоритет ключей можно было бы задавать внутри login scope.

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

При этом у обеих попыток будет один и тот же scope, с точностью до буквы? Да ладно!!!

Вы повторяете то, что я написал выше, об использовании нескольких РАЗНЫХ scope без приоритетов. А отвечаете на совсем другой тезис, об использовании ОДНОГО scope, с приоритетами. Это разные темы.

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

> Envelope - да, там нет возможности задавать именно приоритет, но повторюсь, это сделано из-за того, что в нашем решении нет различия между программными и аппаратными ключами - единообразие.

Но тем не менее в Envelope есть возможность безусловно (unconditionally) запрещать подключение к SL или HL типу ключей. То есть единообразие - это не безусловная и обязательная идеология.
Если сделать в том же Envelope несколько scope - чтобы пробовать по очереди - будет тот же приоритет, фактически.

Например, чтобы общая (unified) программа запускалась в разных режимах, в зависимости от лицензии, когда пользователь может покупать разные лицензии, типа 3 места "обычных" плюс 2 места "делюкс".

> Feature 0 есть во всех ключах

Безусловно. Но вот считать сетевые лицензии удобнее, когда это Envelope делает.

> Сессия автоматически освобождается

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

> настройку необходимо осуществлять через ini файл
"License Manager configuration files can be modified using..."

Читаем. Видим "can be", а вовсе не необходимо.
Кроме того, у обычного пользователя Windows, столкнувшегося с необходимостью, перед глазами GUI ACC, а не нагугленный где-то HowTo
В Линуксе, вероятно, наоборот, и никто не будет даже трогать мышку, если можно все сделать в командной строке через vim.
Но то в Линуксе....

> Перезапуск ПО, для применения некоторых из выставленых опций - вполне нормальная практика как мне кажется.

Да, но с двумя оговорками
1) ПО сообщает, что его нужно перезапустить
2) Перезапускается то ПО, настройки которого изменили, а не ПО на другой машине

> Если бы он разорвал сессию был бы риск потери данных пользователя, с которыми он работает в защищённом приложении

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

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

Ну примерно, как Windows при запросе выключения предупреждает, если на компьютере остаются открытые по сети файлы или залогиненные другие пользователи.
 
 
 
Страницы: 1 2 След.
Читают тему (гостей: 1)

Главная   Описание   Продукты   Решения   Стартовый комплект   Цены и заказ   Поддержка   Контакты