WSCGetApplicationCategory, fonction (ws2spi.h)

Article
03/04/2024

**Remarque** Les fournisseurs de services en couches sont déconseillés. À compter de Windows 8 et Windows Server 2012, utilisez la plateforme de filtrage Windows.

La fonction **WSCGetApplicationCategory** récupère les catégories de fournisseurs de services en couche (LSP) associées à une application.

Syntaxe

int WSCGetApplicationCategory(
  [in]  LPCWSTR Path,
  [in]  DWORD   PathLength,
  [in]  LPCWSTR Extra,
  [in]  DWORD   ExtraLength,
  [out] DWORD   *pPermittedLspCategories,
  [out] LPINT   lpErrno
);

Paramètres

[in] Path

Pointeur vers une chaîne Unicode qui contient le chemin de chargement de l’image exécutable pour l’application. Cette chaîne respecte les règles habituelles de résolution de chemin d’accès et peut contenir des chaînes d’environnement incorporées (telles que %SystemRoot%).

[in] PathLength

Longueur, en caractères, du paramètre Path . Cette longueur n’inclut pas la valeur NULL de fin.

[in] Extra

Pointeur vers une chaîne Unicode qui représente les arguments de ligne de commande utilisés lors du démarrage de l’application spécifiée dans le paramètre Path . Le paramètre Extra permet de distinguer plusieurs instances distinctes d’une application lorsqu’elle est lancée avec une ligne de commande cohérente. Il s’agit de prendre en charge différentes catégorisations d’applications pour différentes instances de Svchost.exe ou de Rundll32.exe. Si seul le paramètre Path est requis et qu’aucun argument de ligne de commande n’est nécessaire pour faire la distinction entre les instances d’une application, le paramètre Extra doit être défini sur NULL.

[in] ExtraLength

Longueur, en caractères, du paramètre Extra . Cette longueur n’inclut pas la valeur NULL de fin.

[out] pPermittedLspCategories

Pointeur vers une valeur DWORD des catégories LSP autorisées qui sont autorisées pour toutes les instances de cette application. L’application est identifiée par la combinaison des valeurs des paramètres Path et Extra .

[out] lpErrno

Pointeur vers le code d’erreur en cas d’échec de la fonction.

Valeur retournée

Si aucune erreur ne se produit, WSCGetApplicationCategory retourne ERROR_SUCCESS (zéro). Sinon, elle retourne SOCKET_ERROR et un code d’erreur spécifique est retourné dans le paramètre lpErrno .

Code d'erreur	Signification
WSAEFAULT	Un ou plusieurs arguments ne se trouve pas dans une partie valide de l’espace d’adressage utilisateur.
WSAEINVAL	Un ou plusieurs arguments ne sont pas valides.
WSASERVICE_NOT_FOUND	Le service est introuvable en fonction des paramètres Path et Extra . L’erreur peut également être retournée si l’application que vous interrogez n’existe pas dans le Registre. Dans ce cas, l’erreur indique que l’application n’est actuellement pas catégorisée.
WSANO_RECOVERY	Une erreur non récupérable s’est produite. Cette erreur est retournée dans plusieurs conditions, notamment : l’utilisateur n’a pas les privilèges d’administration requis pour accéder au registre Winsock ou un échec s’est produit lors de l’ouverture d’une entrée de catalogue Winsock ou d’une entrée d’ID d’application.

Remarques

WSCGetApplicationCategory permet de récupérer les indicateurs de catégorie LSP associés à une application instance. Les applications peuvent déterminer quels comportements LSP sont acceptables dans le contexte de l’application. Par conséquent, en spécifiant des catégories LSP autorisées, une application peut autoriser uniquement les fournisseurs de services en couche qui implémentent des comportements acceptables à être chargés.

Le paramètre Extra est requis lorsque la ligne de commande est utilisée pour faire la distinction entre différentes instances d’une application ou d’un service hébergé dans le même fichier exécutable. Chaque instance peut avoir des besoins de catégorisation d’application différents. Svchost.exe et Rundll32.exe sont deux exemples où la ligne de commande est nécessaire pour différencier les différentes instances de processus. Par SvcHost.exe, le commutateur -k <svcinstance> définit le processus instance.

Pour les services, l’utilisation du nom du service n’est pas suffisante, car le catalogue Winsock est global pour un processus donné et un processus peut héberger plusieurs services.

Les sockets de fenêtre déterminent l’identité d’une application et récupèrent les catégories LSP autorisées lors du premier appel à WSAStartup. Il s’agit de l’ensemble des catégories LSP autorisées pendant la durée de l’application instance. Les modifications ultérieures apportées aux catégories LSP autorisées pour une identité d’application donnée ne seront pas récupérées avant la instance suivante de l’application. Les catégories LSP autorisées ne sont pas mutables pendant la durée de vie de l’application instance.

Winsock 2 prend en charge les protocoles en couches. Un protocole en couches est un protocole qui implémente uniquement des fonctions de communication de niveau supérieur, tout en s’appuyant sur une pile de transport sous-jacente pour l’échange réel de données avec un point de terminaison distant. Un exemple de protocole en couches ou de fournisseur de services en couches serait une couche de sécurité qui ajoute un protocole au processus d’établissement de la connexion afin d’effectuer l’authentification et d’établir un schéma de chiffrement mutuellement convenu. Un tel protocole de sécurité nécessite généralement les services d’un protocole de transport fiable sous-jacent, tel que TCP ou SPX. Le terme protocole de base fait référence à un protocole tel que TCP ou SPX qui est capable d’effectuer des communications de données avec un point de terminaison distant. Le terme protocole en couches est utilisé pour décrire un protocole qui ne peut pas être autonome.

Pendant l’initialisation LSP, le LSP doit fournir des pointeurs vers un certain nombre de fonctions Winsock SPI. Ces fonctions seront appelées pendant le traitement normal par la couche située directement au-dessus du LSP (soit un autre LSP, soit un autre Ws2_32.DLL).

Un fournisseur de services LSP qui implémente un système de fichiers installable (IFS) peut choisir de manière sélective de fournir des pointeurs vers des fonctions implémentées par elle-même, ou de renvoyer les pointeurs fournis par la couche juste sous le LSP. Les fournisseurs de services de sécurité non-IFS, car ils fournissent leurs propres handles, doivent implémenter toutes les fonctions Winsock SPI. Cela est dû au fait que chaque SPI nécessite que le fournisseur LSP mappe tous les handles de socket qu’il a créés au handle de socket du fournisseur inférieur (soit un autre LSP, soit le protocole de base).

Toutefois, tous les fournisseurs LSP effectuent leur travail spécifique en effectuant un traitement supplémentaire sur un sous-ensemble des fonctions SPI winsock.

Il est possible de définir des catégories LSP en fonction du sous-ensemble de fonctions SPI qu’un LSP implémente et de la nature du traitement supplémentaire effectué pour chacune de ces fonctions.

En classant les LSP, ainsi que les applications qui utilisent des sockets Winsock, il devient possible de déterminer de manière sélective si un LSP doit être impliqué dans un processus donné au moment de l’exécution.

Sur Windows Vista et versions ultérieures, un LSP peut être classé en fonction de la façon dont il interagit avec les appels et les données Windows Sockets. Une catégorie LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions SPI Winsock. Par exemple, un filtre de contenu HTTP est classé comme inspecteur de données (catégorie LSP_INSPECTOR). La catégorie LSP_INSPECTOR inspecte (mais ne modifie pas) les paramètres des fonctions SPI de transfert de données. Une application peut interroger la catégorie d’un LSP et choisir de ne pas charger le LSP en fonction de la catégorie LSP et de l’ensemble de catégories LSP autorisées de l’application.

Le tableau suivant répertorie les catégories dans laquelle un LSP peut être classifié.

Catégorie LSP	Description
LSP_CRYPTO_COMPRESS	Le LSP est un fournisseur de chiffrement ou de compression de données.
LSP_FIREWALL	Le LSP est un fournisseur de pare-feu.
LSP_LOCAL_CACHE	Le LSP est un fournisseur de cache local.
LSP_INBOUND_MODIFY	Le LSP modifie les données entrantes.
LSP_INSPECTOR	Le LSP inspecte ou filtre les données.
LSP_OUTBOUND_MODIFY	Le LSP modifie les données sortantes.
LSP_PROXY	Le LSP agit comme un proxy et redirige les paquets.
LSP_REDIRECTOR	Le LSP est un redirecteur réseau.
LSP_SYSTEM	Le LSP est acceptable pour une utilisation dans les services et les processus système.

Un LSP peut appartenir à plusieurs catégories. Par exemple, un pare-feu/LSP de sécurité peut appartenir aux catégories inspecteur (LSP_INSPECTOR) et pare-feu (LSP_FIREWALL).

Si un LSP n’a pas de catégorie définie, il est considéré comme faisant partie de la catégorie Tous les autres. Cette catégorie LSP ne sera pas chargée dans les services ou les processus système (par exemple, lsass, winlogon et de nombreux processus svchost).

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows Vista [applications de bureau uniquement]
Serveur minimal pris en charge	Windows Server 2008 [applications de bureau uniquement]
Plateforme cible	Windows
En-tête	ws2spi.h
Bibliothèque	Ws2_32.lib
DLL	Ws2_32.dll