Выбор ключа из списка разрешенных

Страницы: 1
RSS
Выбор ключа из списка разрешенных, Как программе "указать" ключи к каким можно логиниться?
 
Ситуация следующая:
Клиент, когда скачивает и устанавливает программу, получает Provisional key SL на 90 дней. Допустим, через 10 дней он принимает решение купить программу и получает ключ HL допустим на 2 лицензии. Поработав ещё 20 дней он понимает, что ему 2 лицензии мало и он хочет купить ещё 2. Но по каким-то причинам он желает второй ключик (ничего не противоречит, чтобы в сети было несколько ключей). НО! Объяснять пользователю, как удалить ключ SL - тот ещё геморрой, поэтому, я предусмотрел следующее:
При запуске программы я получаю информацию о всех ключах, которые "видит" программа. Если это только программный "trial key", то логинюсь на него и запускаю программу в режиме "Демо". Если, Hasp.GetInfo вернула информацию, что есть другие "полные" ключи, то ключ "Демо" игнорируется. Но я должен залогинится на какой-нибудь ключ, который не "trial" (на какой - мне фиолетово). Но могу ли я это сделать одной командой Hasp.Login , скажем, передав ему список ID ключей в xml? например так:
<?xml version="1.0" encoding="UTF-8" ?>
<haspscope>
<hasp id="123456789" />
<hasp id="987654321" />
</haspscope>
Или надо будет логиниться на один ключ, в случае неудачи на следующий и т.д. по списку?
 
Добрый день, Валерий.

Если Вам:
Цитата
Валерий Павлов пишет:
на какой - мне фиолетово
В таком случае делаете просто логин на ключ, без привязки к ID ключа, и ПО будет логинется на первый ключ, где найдёт свободную лицензию.
 
В текущем API такой scope будет означать "присоединись к любом из этих ключей, наугад"

> Или надо будет логиниться на один ключ, в случае неудачи на следующий

А тебе нужен приоритет ключей, или все ключи равнозначны ?

PS. но в твоем случае
> получает Provisional key SL
> получает ключ HL допустим на 2 лицензии.

Программа и так будет по возможности соединяться с постояннми ключами, а Provisional -  только по нехватке HL или постоянных SL.
https://www.safenet-sentinel.ru/helpdesk/forum10/topic116/


PPS. Как вариант - можно у Provisional и постоянных сделать разные Feature ID.
Условно, если в сети найдены Feature-ID = 100 (постоянные) - то программа даже не пытается соединиться на Feature-ID=1000 (демо).

Если делать общий Feature ID, то например можно - перебрать все доступные Feature и сгрупировать список ключей, в которых эта Feature вреемнная ( provisional ) и постоянная, после чего сделать два первый login по списку ключей с постоянной feature, а второй - с демо.

Наконец можно просто делать первый логин с параметром "любой HL ключ", не перечисляя явно номера ключей, а второй страховочный логин - "просто любой ключ". Если у вас всегда Provisional - это SL, а постоянный - это HL, то результат будет тот же.
 
Все "Non provisional" ключи равнозначны.
Цитата
Дмитрий Буров пишет:
после чего сделать два первый login по списку ключей с постоянной feature, а второй - с демо
Вот у меня и возник вопрос: Можно ли список ключей задать непосредственно в Hasp.Login, перечислив их ID, или надо делать Hasp.Login на один ключ, в случае отказа, на другой и т.д.?
Цитата
Дмитрий Буров пишет:
Если у вас всегда Provisional - это SL, а постоянный - это HL, то результат будет тот же.
Сейчас так оно и есть, но никакой гарантии, что в будущем не появятся постоянные SL-ключи. Хотелось бы уже сейчас это предусмотреть, чем переписывать потом.
 
Цитата
Валерий Павлов пишет:
Можно ли список ключей задать непосредственно в Hasp.Login, перечислив их ID
Проверьте, хоть даже в Vendor Toolkit.
Можно, но порядок перечисления не имеет значения. Прицепится к люблому из них, при прочих равных условиях, включая фазу луны.


Цитата
Валерий Павлов пишет:
или надо делать Hasp.Login на один ключ, в случае отказа, на другой и т.д.?
И еще раз повторю, зависит от ваших требований к процессу, есть приоритет у ключей или они равнозначны.
Цитата
Валерий Павлов пишет:
никакой гарантии, что в будущем не появятся постоянные SL-ключи
И если появятся - то что? надо будет им занижать приоритет относительно постоянных HL-ключей или нет?

Другой вопрос, что КМК нет гарантий, что завтра у Provisional-лицензий не поднимут приоритет до общего уровня. Сейчас это так, но это на уровне implementation detail...

Я думал перенести чатсь настроек программы в память HASP ключа. Во внутренней утилите так и сделано, удобно. Но для публичных продуктов не стали - именно потому, чтобы игнорировать Provisional SL при покупке постоянного ключа. Prov. ключ сам умрёт через 90 дней, а программа будет с HL ключом работать автоматически. Ничего делать не нужно.
Страницы: 1
Читают тему (гостей: 1)