Ce point d'accès renvoie des informations sur le site Netskope Client.
Point final de la demande
https://<tenant-URL>/api/v1/clients
Valid query parameters are:
| Clé | Value | Description |
|---|---|---|
token | string | Il s'agit d'une obligation. Le jeton obtenu sur la page de l'API REST dans l'interface utilisateur de Netskope ( Settings > Tools > Rest API v1) est nécessaire. Nous vous recommandons de placer le jeton dans le corps de la demande, et non dans l'URL du point final. |
query | Requête valide sur les différents champs. | Il s'agit d'un filtre sur toutes les entrées de la base de données. |
limit | Entier positif inférieur à 5000 | Les réponses de l'API REST peuvent renvoyer jusqu'à 5000 événements dans une seule réponse. Vous pouvez utiliser la pagination pour obtenir davantage de résultats. |
skip | Nombre entier positif | Sauter certains événements (utile pour la pagination en combinaison avec la limite). |
Note
Les champs de requête pour ce point d'accès sont légèrement différents des autres. Pour le savoir, il faut d'abord obtenir une liste de clients, voir les données renvoyées, puis définir la requête en conséquence.
Exemple de demande de données d'un client
POST https://<tenant-URL>/api/v1/clients
{
"token": "f32a973eddd7bc1602fc0f48dc0a",
"query": "host_info"}
Response
Le nom d'hôte est renvoyé comme suit :
{
"_id": ,
"client_install_time":
"device_id": ,
"host_info":
{
"device_make": ,
"device_model": ,
"hostname": ,
"os": ,
"os_version":
"nsdeviceuid":
},
"last_event":
{
"actor": ,
"event": ,
"status": ,
"timestamp":
},
"users":
[
{
"_id": ,
"client_version": ,
"device_classification_status": ,
"last_event":
{
"actor": ,
"event": ,
"status": ,
"timestamp":
},
"user_added_time":,
"user_source": ,
"userkey": ,
"username":
}
]
}
La requête pour un hôte particulier devrait donc ressembler à host_info.hostname eq 'xxx' ou host_info.hostname eq 'yyy'.
Le backend renvoie l'état de nombreux champs sous forme de valeurs numériques. Dans l'interface utilisateur, ils sont convertis en texte lisible, mais pas dans l'API REST. Les correspondances sont indiquées ci-dessous :
"device_classification_status": {
"managed": 0,
"unmanaged": 1,
"unknown": 2
},
"last_event": {
"status": {
"Disabled": 0,
"Enabled": 1,
"Uninstalled": 2
},
"event": {
"Installed": 0,
"Tunnel Up": 1,
"Tunnel Down": 2,
"Tunnel down due to Secure Forwarder": 3,
"Tunnel down due to config error": 4,
"Tunnel down due to error": 5,
"User Disabled": 6,
"User Enabled": 7,
"Admin Disabled": 8,
"Admin Enabled": 9,
"Uninstalled": 10,
"Installation Failure": 11
},
"actor":{
"User": 0,
"Admin": 1,
"System": 2
}
},
"user_source": {
"Directory": 0,
"Manual": 1
}
"host_info": {
os: {
"Windows": 0,
"Mac": 1,
"Android": 3,
"Windows Server": 4
}
}
La hiérarchie est importante. Ainsi, pour rechercher les derniers événements, la requête doit être adressée à last_events.status = 0 afin de trouver les événements désactivés.