Подключение к агенту на хосте через KSC13 OpenAPI

[GrimAnEye 0]

Я автоматизирую инфраструктуру и для скрипта мне нужно временно приостановить антивирус на хосте.

 

Я нашел описание (ужасного) API и через два дня пришел к следующему:

 

Использую Session.StartSession -> получаю «sessionID»

С «sessionID» -> Использую HostGroup.FindHosts -> получаю «RequestID»

С «sessionID», «RequestID» -> Использую ChunkAccessor.GetItemsChunk -> получаю «hostnameID»

С «sessionID», «hostnameID» -> Использую CgwHelper.GetNagentLocation -> получаю «locationObj»:

{
  "PxgRetVal": {
    "GwLocHostId": "4f0737f2-9885-46f4-8437-3ba72e50103c",
    "GwLocIndirect": true,
    "GwLocLocation": "http://172.20.23.121:15000",
    "GwLocSignUdp": true,
    "GwLocTargetComponent": "1103;86;1.0.0.0;b736452e-8f9d-42b0-a6bc-251535210f7a",
    "GwLocUseCompression": true
  }
}

 С «locationObj» в качестве массива → пытаемся использовать GatewayConnection.PrepareGatewayConnection:

{
"pLocations":
	[{
 "GwLocHostId": "4f0737f2-9885-46f4-8437-3ba72e50103c",
 "GwLocIndirect": true,
 "GwLocLocation": "http://172.20.23.121:15000",
 "GwLocSignUdp": true,
 "GwLocTargetComponent": "1103;86;1.0.0.0;b736452e-8f9d-42b0-a6bc-251535210f7a",
 "GwLocUseCompression": true
}]
}

 

И я получаю ошибку:

{
  "PxgError": {
    "code": 1192,
    "file": "c:\\a\\b\\a_6vlf7p9h\\s\\csadminkit\\development2\\kloapi\\contentstream\\sax_handler.cpp",
    "line": 314,
    "message": "Field 'type' is not found for the value with name: ",
    "module": "KLSTD",
    "subcode": 0
  }
}

 

При этом ничего полезного в документации по этому поводу нет:

https://support.kaspersky.com/help/KSC/13/KSCAPI/a00478_a5983b9b35b07657ef3afdc864c4d6c7e.html#a5983b9b35b07657ef3afdc864c4d6c7e

Что делать?

[oit 2 139]

52 минуты назад, GrimAnEye сказал:

делать?

Обратиться в ТП

[GrimAnEye 0]

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

https://community.kaspersky.com/kaspersky-corporate-products-27/how-to-disable-kes-on-a-host-via-open-ksc-api-18551?postid=83471#post83471

https://community.kaspersky.com/produkty-kaspersky-dlya-biznesa-31/podklyuchenie-k-agentu-na-hoste-cherez-ksc13-openapi-18564?postid=83470#post83470

[GrimAnEye2 0]

Знаете что здорово? То, что я еще больше убеждаюсь, что API KSC плохой. Как думаете, что могло произойти с уже написанным  playbook во время рефакторинга? Правильно, он снова споткнулся об эту ошибку.

А знаете, почему я думаю, что API плохой, а всех остальных хочется послать более крепким словцом?

Потому что тему с ответом в соседнем форуме удалили! Здорово правда? Форум для решения проблем с этим чудовищем, а пост с решением удален с форума! Отлично!

 

Хоть api и работает, после долгого времени решения, причины, почему я считаю api KCS плохим:

1. Плохая документация - сложно найти требуемые элементы, т.к. они представлены в виде списка одиночных функций. Формально говоря - документация к API предназначена для работы через CLI а не REST. Плохо работает поиск по ключевым словам. Формально - не работает.

1.1 Предложение - перевести документацию для REST API на что-то вроде Swagger. В таком случае будет:

1. Видна взаимосвязь конечных точек
2. Возможность их группировки по категориям
3. Структура и возможность увидеть примеры запроса

2. Название аргументов к запросам и ответам представлены в виде аббревиатур, через одну включающих инициалы названия сервиса. Зачем включать мусорные символы в название аргумента? Например:

REST API: ChunkAccessor.GetItemsChunk
Ответ: {
	"pChunk": {
		"KLCSP_ITERATOR_ARRAY": [
			{
				"type": "params",
				"value": {
					"KLHST_WKS_HOSTNAME": "f652a0af-e219-4716-9064-1da7d59decfd"
				}
			}
		]
	},
	"PxgRetVal": 1
}

Зачем здесь задвоение в названии  KLHST_WKS_HOSTNAME? А за что означают эти символы KLCSP_ITERATOR_ARRAY, KLHST_WKS_HOSTNAME ? Касперский? Спасибо, при общении с таким API эту информацию фиг забудешь.

Что есть WKS? Для чего в ответе ITERATOR_ARRAY? Хочешь массив - делай массив, для чего плодить объекты с длинными бессмысленными названиями?

А божественные ответы в виде ёлочки? Почему нельзя получить ёмкий ответ на заданный запрос, для чего плодить монструозную вложенность объектов - вам платят как Маяковскому - построчно? Пример:

{
	"PxgRetVal": {
		"KLHST_APP_INFO": {
			"type": "params",
			"value": {
				"1103": {
					"type": "params",
					"value": {
						"1.0.0.0": {
							"type": "params",
							"value": {
								"KLHST_APP_STATE": 3,
								"KLHST_APP_STATE_TIME": {
									"type": "datetime",
									"value": "2023-04-03T11:43:11Z"
								}
							}
						}
					}
				},
				"KES": {
					"type": "params",
					"value": {
						"11.0.0.0": {
							"type": "params",
							"value": {
								"KLHST_APP_STATE": 3,
								"KLHST_APP_STATE_TIME": {
									"type": "datetime",
									"value": "2023-04-03T11:43:11Z"
								}
							}
						}
					}
				}
			}
		}
	}
}

2.1. Предложение:

1. Дать конечным точкам и аргументам ёмкие названия, отражающие их суть. Не можешь уложиться максимум в 2 слова - значит название неудачное.
2. Выходная глубина Марианской впадины в ответе не имеет никакой пользы, а только добавляет проблемы при разборе экранирующих символов. В самом сервисе может быть любая глубина зависимости между объектами, но на внешнем API должно быть минимум информации, представлена она должна быть максимально емко. Объект - все требуемые свойства на одном уровне. Список - родительский объект -> дочерние объекты, без посредников.

3. Множественные ошибки при возврате сообщений по REST API, вида:

1. 200 код, при ошибке
2. отсутствие заголовков, например "application/json" для возвращаемого json
3. Отсутствие вменяемой причины, почему возникла ошибка, а так же отсутствие синтаксиса и описания, как сделать правильно

Всё вышесказанное относится к первому сообщению поста.

Тут уже не предложение, а обязанность как разработчика REST API сервиса:

1. Привести в порядок заголовки ответов. Многие службы привязаны к правильным заголовкам ответа и автоматически выполняют регламентные операции при их обнаружении. При их отсутствии - хорошо, если есть возможность в ручной обработке ответа. Плохо, что это может быть не очевидно, поскольку 3.3
2. Привести в порядок коды возвращаемых ответов и их описание. Для большинства ситуаций существуют стандартные коды, способные отработать большинство ситуаций. Возвращать ошибку сервиса в виде 200 - неправильно.

[mike 1 1 093]

Добрый день. Ваши предложения и замечания по работе продукта, вы можете оставить через запрос в техподдержку через портал https://companyaccount.kaspersky.com/

[kmscom 2 286]

4 часа назад, GrimAnEye2 сказал:

Потому что тему с ответом в соседнем форуме удалили!

про какой соседний форум речь? вы помните название темы?

если про прежнее комьюнити https://community.kaspersky.com/ то оно закрыто, по независящим от компании обстоятельствам.