Анализ ошибок проверки сетевого ключа с помощью API

Доброго времени суток, не нашёл конкретного ответа на вопрос в этом форуме, поэтому спрошу ещё раз: задача такая - мне нужно проанализировать ошибку проверки сетевого ключа Guardant Net (как я понял на отсутствие ключа в компьютере сервера, да перезагрузку сервера и на отсутствие локальной сети проверка должна реагировать по разному), функция GrdCheck не подходит так как выдает только два значения, мне нужен анализ почему же нет доступа к ключу, возможно ли это реализовать?
(Win7 Домашняя Расширенная, CodeGear Delphi 2007)

Re: Анализ ошибок проверки сетевого ключа с помощью API

Добрый день, Fraus Kilma.

Функция GrdCheck, как и указанно в ее описании, в качестве выходных параметров выдает стандартные коды возврата ошибок (подробнее см. справку по Guardant API: файл «GrdAPI.chm», по умолчанию в папке: %Program Files%\Guardant\Guardant 6\%Public Code%\Doc\), которые и следует анализировать.

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

Re: Анализ ошибок проверки сетевого ключа с помощью API

Использовал GRDCheck, GrdFormatMessage (с ненулевым Handle), GrdGetLastError, при перезагрузке сервера ключей, отсутствии сети, отсутствии самого ключа на сервере и выдаёт одну единственную ошибку 46 (GrdE_InvalidArg, Задано недопустимое значение одного из аргументов функции) - на основе этой ошибки невозможно построить систему анализа проверки ключа. Не подскажите ли какая из API функций может выдать например ошибки {GrdE_NetDongleNotFound,GrdE_NetServerReloaded, GrdE_NetConnectionLost }

Re: Анализ ошибок проверки сетевого ключа с помощью API

Fraus Kilma пишет:

Не подскажите ли какая из API функций может выдать например ошибки {GrdE_NetDongleNotFound,GrdE_NetServerReloaded, GrdE_NetConnectionLost }

Ошибка GrdE_NetDongleNotFound, например, характерна для функции GrdFind, а ошибки GrdE_NetServerReloaded и GrdE_NetConnectionLost всегда являлись весьма специфическими, проявлялись редко и для последних версий (6.х) сервера сетевых ключей Guardant Net, Guardant API и автозащиты проявляться не должны.

В целом, построение системы анализа состояния, например, сетевых интерфейсов ПК при помощи Guardant API не совсем правильно, в общем случае все сводится к детектированию факта наличия валидного для защищенного приложения ключа. Дополнительная диагностическая информация, в этом смысле, достаточно скудна и проверять состояние ЛВС, доступность сервера с выяснением конкретных причин сбоя с ее помощью едва ли удастся.

Отдельно хочу отметить что в нашем  стандартном примере по использованию API (примеры для разных сред разработки можно найти в папке «\Samples» установленного комплекта разработчика - директория по умолчанию: %Program Files%\Guardant\Guardant 6\%Public Code%\Samples) показан некоторый, на наш взгляд достаточно оптимальный, механизм анализа кодов ошибок функций API.

(2013-07-25 14:38:13 отредактировано Искандер)

Re: Анализ ошибок проверки сетевого ключа с помощью API

Добрый день!

Можете уточнить, почему может появляться ошибка GrdE_NetConnectionLost ?

Используется для защиты API и сервер 6.2. У себя не могу воспроизвести, а у одного из многих пользователей это происходит на начальном этапе инициализации и чтения защищенной ячейки при, в общем то стандартной, последовательности вызовов SetFindMode-Find-Login-SetWorkMode-PIRead. При этом Web-интерфейс на сервер работает без проблем, ini-файлы на сервере и клиенте стандартные.

Re: Анализ ошибок проверки сетевого ключа с помощью API

Добрый день.

Искандер пишет:

Добрый день!

Можете уточнить, почему может появляться ошибка GrdE_NetConnectionLost ?

Используется для защиты API и сервер 6.2. У себя не могу воспроизвести, а у одного из многих пользователей это происходит на начальном этапе инициализации и чтения защищенной ячейки при, в общем то стандартной, последовательности вызовов SetFindMode-Find-Login-SetWorkMode-PIRead. При этом Web-интерфейс на сервер работает без проблем, ini-файлы на сервере и клиенте стандартные.

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

Тут следует убедиться, что в ЛВС клиента и на целевом компьютере, нет никаких механизмов (настройки маршрутизации, доменные политики, средства проактивной защиты (антивирусы, антиспамы, брандмауэры и.тп)) препятствующих обмену трафиком между защищенным приложением и сервером Guardant Net.

Для того чтобы однозначно исключить влияние подобных факторов следует выполнить проверку по следующему алгоритму:

1) Взять два ПК полностью отключенных от ЛВС (желательно не те на которых ведется текущее тестирование);
2) На одном установить драйвер, подсоединить ключ и запустить сервер Guardant Net, а на другом установить защищенное приложение;
3) Соединить данные две машины, прямым (без использования хабов или маршрутизаторов), кроссовым патчкордом;
4) Вручную настроить стандартную (вида: 192.168.x.x) подсеть между данными компьютерами;
5) Выключить абсолютно все средства проактивной защиты запущенные на обоих компьютерах;
6) Запустить защищенное приложение на ПК-клиенте.