> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Vue d'ensemble de WinHTTP > Vue d'ensemble de WinHTTP Cet article explique comment utiliser les fonctionnalités de [Windows HTTP Services (WinHTTP)](https://learn.microsoft.com/windows/desktop/winhttp/winhttp-start-page) pour un titre du Microsoft Game Development Kit (GDK). Il s'agit d'une API cliente HTTP de bas niveau disponible pour les titres du Microsoft Game Development Kit (GDK) sur PC et sur console XBOX. Vous pouvez l'utiliser pour créer des points de terminaison de service HTTP et WebSocket classiques. Comme elle est de bas niveau, il y a davantage de considérations et d'étapes à mettre en œuvre pour obtenir une communication sécurisée et robuste pour votre titre. Nous vous recommandons de faire en sorte que l'implémentation de votre titre respecte toutes les [bonnes pratiques de sécurité des communications (article sous NDA)](/fr/build/game-principles/security/communication-security-overview). ## Différences entre les versions de WinHTTP En général, les titres du Microsoft Game Development Kit (GDK) interagissent avec WinHTTP de la même façon que les applications Win32. Lors du développement de titres du Microsoft Game Development Kit (GDK), seule l'API C/C++ plate de WinHTTP est disponible. Cela signifie que les fonctionnalités HTTP doivent être construites sur cette API cliente HTTP. ## Ajouter WinHTTP à votre projet de console XBOX Sur console, vous devez utiliser `#include ` dans vos fichiers sources. Vous devez effectuer l'édition de liens avec `XGamePlatform.lib` plutôt que directement avec `Winhttp.lib`. Seules les API de la famille d'API `WINAPI_PARTITION_GAMES` fonctionnent dans les titres du Microsoft Game Development Kit (GDK). Sur PC Windows, vous devez continuer à effectuer l'édition de liens avec `Winhttp.lib`. Pour obtenir un exemple d'intégration de WinHTTP dans votre titre du Microsoft Game Development Kit (GDK), consultez l'[exemple SimpleWinHttp](https://aka.ms/gdkdl). Il constitue un bon point de départ pour votre propre implémentation de WinHTTP et inclut la classe `WinHttpManager`. Celle-ci expose une surface d'API asynchrone simple. ## Initialisation du réseau et WinHTTP Avant que votre titre n'effectue le premier appel à [WinHttpOpen](https://learn.microsoft.com/windows/desktop/api/winhttp/nf-winhttp-winhttpopen), les titres du Microsoft Game Development Kit (GDK) doivent s'assurer que la pile réseau est initialisée. Si `WinHttpOpen` est appelée trop tôt pendant le processus de lancement du titre, `WinHttpOpen` ou les appels WinHTTP suivants peuvent échouer ou planter de manière non déterministe. Avant que le réseau ne soit déclaré comme initialisé, des requêtes peuvent sembler réussir alors qu'elles échouent en réalité, ou inversement. Pour savoir comment déterminer quand la pile réseau est initialisée, consultez [Initialisation du réseau](/fr/build/console-features/networking/initialization-connectivity-networking#network-initialization). ## Suspension et reprise du titre et WinHTTP Les titres doivent lancer le processus de fermeture de tous les handles WinHTTP lorsqu'une notification de suspension du titre est reçue. Le nettoyage des handles WinHTTP est asynchrone. Par conséquent, vous devez fermer vos handles dans l'ordre suivant : tous les handles de requête, puis tous les handles de connexion, puis tous les handles de session. La nature asynchrone du nettoyage des handles WinHTTP vise à garantir la sécurité des threads de notification. Bien qu'il soit asynchrone, le nettoyage des handles WinHTTP n'introduit aucun délai, ce qui lui permet de s'inscrire facilement dans le délai de report de suspension d'une seconde. Lors de la reprise, les titres doivent suivre la même procédure que celle décrite dans la section précédente, Initialisation du réseau et WinHTTP, et attendre que le réseau revienne à l'état prêt avant de continuer à utiliser WinHTTP. Une longue période peut s'être écoulée entre les événements de suspension et de reprise, ce qui oblige le réseau à se stabiliser à nouveau avant que les API WinHTTP ne redeviennent déterministes. ## Considérations relatives à la mémoire et à la concurrence Le nombre de requêtes WinHTTP simultanées doit toujours rester inférieur à huit pour garantir que l'état asynchrone de WinHTTP fonctionne correctement et dans les limites de son budget mémoire. Cette limite s'applique à toutes les opérations simultanées au sein du runtime du titre, y compris les appels provenant des API des services XBOX et de `XCurl`. En complément des [considérations relatives à la mémoire de WinSock](/fr/build/console-features/networking/game-mesh/winsock-intro-networking#SocketMemory), lors de la réception de données, vous devez toujours disposer d'une mémoire tampon en attente avec `WinHttpReadData` (ou attendre un rappel d'un appel à `WinHttpQueryDataAvailable`) afin de transférer les données des pools de mémoire en mode noyau vers votre processus en mode utilisateur aussi rapidement que possible et de minimiser la quantité de mémoire noyau consommée par votre opération HTTP. La fonction d'accès `WinHttpQueryHeaders` nécessite des allocations de mémoire temporaires. Elle alloue, pour un usage interne, une mémoire tampon de travail de taille égale au paramètre `lpdwBufferLength` (et la libère avant le retour de la fonction). C'est pourquoi vous devez utiliser le modèle de double appel `WINHTTP_NO_OUTPUT_BUFFER` pour minimiser la taille des mémoires tampons de travail, et limiter le nombre d'appels simultanés à `WinHttpQueryHeaders` afin d'éviter une utilisation excessive de la mémoire système susceptible d'entraîner une instabilité du système. La taille maximale par défaut des en-têtes est de 64 Ko, comme spécifié par l'option WinHTTP `WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE`. ## Considérations relatives à WinHttpOpen ### Indicateurs Vous devez passer les indicateurs du tableau suivant à [WinHttpOpen](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpopen). | Paramètre | Valeur | | - | - | | `dwAccessType` | `WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY` | | `pszProxyW` | `WINHTTP_NO_PROXY_NAME` | | `pszProxyBypassW` | `WINHTTP_NO_PROXY_BYPASS` | | `dwFlags` | `WINHTTP_FLAG_SECURE_DEFAULTS` | La combinaison de `WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY`, `WINHTTP_NO_PROXY_NAME` et `WINHTTP_NO_PROXY_BYPASS` permet à la plateforme du Microsoft Game Development Kit (GDK) de gérer automatiquement les proxys tels que [Fiddler](/fr/build/console-features/networking/tools/fiddler-setup-networking) et d'autres environnements réseau atypiques. L'indicateur `WINHTTP_FLAG_SECURE_DEFAULTS` est un nouvel indicateur conçu pour aider les titres du Microsoft Game Development Kit (GDK) à respecter les bonnes pratiques de sécurité en définissant le comportement de connexion sécurisée recommandé. Il est disponible sur les consoles XBOX One et le sera sur PC Windows dans une future mise à jour du système d'exploitation Windows. Tenter de passer `WINHTTP_FLAG_SECURE_DEFAULTS` sur les versions existantes du système d'exploitation Windows entraîne un échec pour paramètre non valide. Cet indicateur a un effet secondaire important : il force WinHTTP en mode asynchrone, car il inclut implicitement l'indicateur `WINHTTP_FLAG_ASYNC`. Sur les versions du système d'exploitation Windows pour PC qui ne prennent pas en charge cet indicateur, vous devez passer `WINHTTP_FLAG_ASYNC` à la place afin de minimiser les différences dans le reste de votre implémentation WinHTTP. L'indicateur `WINHTTP_FLAG_SECURE_DEFAULTS` nécessite qu'un indicateur `WINHTTP_FLAG_SECURE` correspondant soit passé à `WinHttpOpenRequest` et bloque les requêtes HTTP non chiffrées. Sur les kits de développement, à des fins de débogage et de test internes, vous pouvez créer un handle de session WinHTTP et spécifier l'indicateur `WINHTTP_FLAG_ASYNC` pour `WinHttpOpen`. Cet indicateur vous permet d'effectuer une requête HTTP non chiffrée pendant le développement en ne spécifiant pas l'indicateur `WINHTTP_FLAG_SECURE` pour `WinHttpOpenRequest`. Vous devez néanmoins utiliser des handles de session ouverts avec `WINHTTP_FLAG_SECURE_DEFAULTS` pour le trafic hors débogage afin de reproduire le comportement des requêtes que votre titre rencontre en RETAIL. ### WINHTTP\_OPTION\_SECURE\_PROTOCOLS Après avoir créé un nouveau handle de session avec `WinHttpOpen`, vous devez appeler [WinHttpSetOption](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpsetoption) avec l'option `WINHTTP_OPTION_SECURE_PROTOCOLS` et passer la valeur `XNetworkingSecurityInformation::enabledHttpSecurityProtocolFlags` correspondante, récupérée par un appel à [XNetworkingQuerySecurityInformationForUrlUtf16Async](/fr/reference/networking/xnetworking/functions/xnetworkingquerysecurityinformationforurlutf16async) pour une URL correspondant à celle pour laquelle ce handle de session sera utilisé. Vous devez également stocker la structure [XNetworkingSecurityInformation](/fr/reference/networking/xnetworking/structs/xnetworkingsecurityinformation) dans votre objet de contexte pour l'utiliser ultérieurement lors de la validation de la négociation TLS/SSL. ### Mise en cache des handles de session Les handles de session HTTP créés via `WinHttpOpen` sont coûteux en mémoire et entraînent un coût de démarrage important qui retarde la première requête HTTP. Nous vous recommandons de mettre en cache les handles de session HTTP autant que possible dans votre titre afin d'éviter ces coûts. Toutefois, il n'est pas possible de modifier l'option `WINHTTP_OPTION_SECURE_PROTOCOLS` sur un handle de session. Vous devez conserver un cache de valeurs `XNetworkingSecurityInformation::enabledHttpSecurityProtocolFlags` associées aux handles de session WinHTTP afin de disposer d'un handle de session différent pour chaque indicateur de protocole sécurisé différent. Le cache que gère votre titre doit être vidé lors des notifications de suspension et doit être entièrement reconstruit lors de la reprise (après avoir attendu que le réseau soit initialisé). ## Considérations relatives à WinHttpConnect Contrairement aux handles de session, les handles de connexion créés via [WinHttpConnect](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpconnect) ne doivent jamais être mis en cache. De nouveaux handles doivent être créés pour chaque nouvelle requête et/ou nouvelle tentative. Malgré leur nom, les handles de connexion WinHTTP n'ont aucun rapport avec les connexions TCP (Transmission Control Protocol) sous-jacentes au serveur. WinHTTP gère la durée de vie des connexions sous-jacentes au serveur avec le handle de session et réutilise automatiquement les connexions ouvertes au serveur lorsque c'est possible pour les nouveaux handles de connexion. ### Canonisation des URL WinHTTP s'attend à ce que toutes les URL soient canonisées en caractères US-ASCII a-z, A-Z et 0-9. Pour plus d'informations sur la canonisation, consultez [Uniform Resource Locators (URL) dans WinHTTP](https://learn.microsoft.com/windows/win32/winhttp/uniform-resource-locators--urls--in-winhttp). Dans la mesure du possible, nous vous recommandons de coder en dur les URL utilisées par votre titre sous leur forme canonique. Cette forme évite les allocations de mémoire et les problèmes de performances liés à l'utilisation des fonctions [WinHttpCrackUrl](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpcrackurl) et [WinHttpCreateUrl](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpcreateurl) pour canoniser dynamiquement vos URL. ### Fractionnement des URL WinHTTP exige qu'une chaîne de nom d'hôte terminée par un caractère null soit passée à `WinHttpConnect`, tandis que le chemin et l'objet sont passés à `WinHttpOpenRequest`. Votre titre doit passer l'URL complète, c'est-à-dire la concaténation du nom d'hôte et du chemin, à certains endroits, et uniquement le nom d'hôte ou le chemin à d'autres. Nous vous recommandons de coder en dur les deux dans votre titre afin d'éviter d'avoir à utiliser [WinHttpCrackUrl](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpcrackurl) et [WinHttpCreateUrl](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpcreateurl) pour concaténer ou fractionner dynamiquement les URL. ## Considérations relatives à WinHttpOpenRequest Comme les handles de connexion WinHTTP, les handles de requête WinHTTP créés via la fonction [WinHttpOpenRequest](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpopenrequest) ne doivent jamais être mis en cache. De nouveaux handles doivent être créés pour chaque nouvelle requête et/ou nouvelle tentative. Par bonne pratique de sécurité, les titres doivent toujours passer l'indicateur `WINHTTP_FLAG_SECURE` pour le paramètre `dwFlags` lors de l'appel à la fonction `WinHttpOpenRequest`. ## Récupération et application des jetons des services XBOX Les jetons ne sont pas insérés automatiquement pour les titres du Microsoft Game Development Kit (GDK). Le titre doit plutôt récupérer les jetons et signatures d'authentification des services XBOX à l'aide des API [XUser](/fr/reference/system/xuser/xuser_members) du Microsoft Game Development Kit (GDK). Une fois que le titre dispose d'un utilisateur, il doit appeler [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async) pour récupérer les chaînes de jeton et de signature pour chaque requête. Ces deux chaînes doivent ensuite être passées sous forme d'en-têtes dans l'appel à `WinHttpAddRequestHeadersEx`, [WinHttpSendRequest](https://learn.microsoft.com/windows/desktop/api/winhttp/nf-winhttp-winhttpsendrequest) ou [WinHttpAddRequestHeaders](https://learn.microsoft.com/windows/desktop/api/winhttp/nf-winhttp-winhttpaddrequestheaders). Pour générer une signature correcte, [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async) s'attend à ce que le titre passe tous les en-têtes et l'intégralité du corps. Pour un `POST` ou un `PUT` avec un corps volumineux, le titre peut passer un sous-ensemble du corps configuré dans l'Espace partenaires. Pour plus d'informations, consultez [Services web (rubrique sous NDA)](/fr/services/xbox-services/fundamentals/s2s-auth-calls/custom-service-config/web-services/live-web-services-nav). Pour l'instant, le réseau XBOX ne fournit aucun mécanisme permettant de récupérer cette configuration. Les clients doivent soit coder les valeurs en dur, soit les récupérer via un point de terminaison personnalisé propre au titre. [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async) effectue en interne toute la mise en cache nécessaire et doit être appelée pour chaque tentative HTTP, y compris les nouvelles tentatives. Si le titre reçoit un code d'état de réponse HTTP 401 Unauthorized pour une requête HTTP quelconque, il doit relancer la requête et forcer l'actualisation du jeton d'authentification des services XBOX. Cette actualisation s'effectue en récupérant un nouveau jeton avec [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async) et en passant la valeur d'énumération [XUserGetTokenAndSignatureOptions::ForceRefresh](/fr/reference/system/xuser/enums/xusergettokenandsignatureoptions). Une fois que le titre dispose de [XUserGetTokenAndSignatureUtf16Data](/fr/reference/system/xuser/structs/xusergettokenandsignatureutf16data), récupérée par un appel à [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async), il doit transformer `XUserGetTokenAndSignatureUtf16Data::Token` et `XUserGetTokenAndSignatureUtf16Data::Signature` en en-têtes HTTP à passer à WinHTTP. Une nouvelle API WinHTTP, `WinHttpAddRequestHeadersEx`, a été ajoutée spécifiquement pour réduire la complexité pour les titres du Microsoft Game Development Kit (GDK). Un exemple d'utilisation de cette nouvelle API est présenté ci-dessous. Cette nouvelle API est disponible sur les consoles XBOX One et le sera sur PC Windows dans une future mise à jour du système d'exploitation Windows. Sur console, nous vous recommandons d'utiliser `WinHttpAddRequestHeadersEx` pour éviter les allocations supplémentaires et les modifications de format de chaîne. ```cpp theme={null} HRESULT AddTokenAndSignatureDataToHttpRequest( XUserGetTokenAndSignatureUtf16Data* userTokenAndSignatureData, HINTERNET requestHandle ) { WINHTTP_EXTENDED_HEADER winhttpHeader[2]; winhttpHeader[0].pwszName = L"Authorization"; winhttpHeader[0].pwszValue = userTokenAndSignatureData->token; winhttpHeader[1].pwszName = L"Signature"; winhttpHeader[1].pwszValue = userTokenAndSignatureData->signature; return HRESULT_FROM_WIN32(WinHttpAddRequestHeadersEx( m_handshakeRequest, WINHTTP_ADDREQ_FLAG_ADD, WINHTTP_EXTENDED_HEADER_FLAG_UNICODE, 0, tokenAndSignature->signatureCount ? 2 : 1, winhttpHeader)); } ``` L'appareil ou un compte connecté doit avoir accès au sandbox sur lequel il est configuré. Sinon, `XUserGetTokenAndSignatureUtf16Data` échoue. ### Utilisation de la liste d'autorisation de sécurité réseau XBOX (NSAL) Le réseau XBOX utilise la NSAL pour garantir que les clients établissent des connexions sécurisées et authentifiées à vos services web. Les titres gèrent le contenu de la NSAL dans le cadre de leur configuration dans l'Espace partenaires. Pour plus d'informations, consultez [Configuration des services web dans l'Espace partenaires (rubrique sous NDA)](/fr/services/xbox-services/fundamentals/s2s-auth-calls/custom-service-config/web-services/live-web-services). La configuration de la NSAL est ensuite téléchargée automatiquement pour chaque titre. Elle est utilisée à la fois pour générer les jetons des services XBOX appropriés et pour effectuer l'épinglage de certificats pour les points de terminaison propres à votre titre.} ## Considérations relatives à la machine à états asynchrone de WinHTTP La machine à états asynchrone de WinHTTP est la même sur console que sur PC Windows. Pour inscrire une fonction de rappel auprès d'une ou plusieurs notifications, utilisez la fonction [WinHttpSetStatusCallback](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpsetstatuscallback). Nous recommandons d'utiliser l'indicateur `WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS` pour le paramètre `dwNotificationFlags` à des fins de débogage, car WinHTTP est relativement détaillé et transparent sur ce qu'il fait. Bien que la plupart des notifications ne nécessitent aucune action de votre part, la journalisation des données peut être utile pour découvrir la cause racine des problèmes. WinHTTP utilise un seul thread pour les notifications. Les titres doivent éviter autant que possible de bloquer une fonction de notification, car cela empêche la progression de toutes les requêtes HTTP au sein de votre processus. Les notifications non traitées peuvent également augmenter la mémoire en mode noyau, ce qui peut entraîner des plantages. WinHTTP ne copie pas vos mémoires tampons d'envoi ou de réception et exige que vous les mainteniez allouées jusqu'au rappel d'achèvement correspondant. Veillez à maintenir vos mémoires tampons d'envoi allouées et valides à partir du moment où vous appelez [WinHttpSendRequest](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpsendrequest) jusqu'à la réception de la notification `WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE` correspondante. De même, chaque fois que vous appelez [WinHttpReadData](https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpreaddata), veillez à maintenir votre mémoire tampon de réception allouée et valide jusqu'à la réception de la notification `WINHTTP_CALLBACK_STATUS_READ_COMPLETE` correspondante. Nous recommandons également d'utiliser une mémoire tampon de réception d'au moins 8 Ko afin d'éviter les problèmes de récursivité pouvant entraîner un épuisement de la pile. Les titres doivent également s'assurer que les mémoires tampons WinHTTP sont correctement vidées en poursuivant le cycle asynchrone `WinHttpQueryDataAvailable`/`WinHttpReadData` et en ne bloquant jamais les rappels WinHTTP. ### Validation de la négociation TLS (Transport Layer Security)/SSL (Secure Sockets Layer) Par bonne pratique de sécurité, les titres doivent valider la négociation TLS/SSL et utiliser uniquement TLS 1.2. Une validation supplémentaire est effectuée dans la notification `WINHTTP_CALLBACK_STATUS_SENDING_REQUEST`. Dans cette notification, vous devez appeler la fonction [XNetworkingVerifyServerCertificate](/fr/reference/networking/xnetworking/functions/xnetworkingverifyservercertificate) et lui passer la structure [XNetworkingSecurityInformation](/fr/reference/networking/xnetworking/structs/xnetworkingsecurityinformation) récupérée lors d'un appel correspondant précédent à [XNetworkingQuerySecurityInformationForUrlUtf16Async](/fr/reference/networking/xnetworking/functions/xnetworkingquerysecurityinformationforurlutf16async). Cette fonction échoue si la chaîne de certificats n'est pas valide. Vous devez alors fermer *immédiatement* le handle WinHTTP avant la fin du rappel afin de garantir qu'aucune donnée n'est transférée vers ou depuis le serveur compromis. En plus de valider les chaînes de certificats, la fonction [XNetworkingVerifyServerCertificate](/fr/reference/networking/xnetworking/functions/xnetworkingverifyservercertificate) est requise pour le fonctionnement de Fiddler sur console. ## Débogage de WinHTTP [Fiddler](/fr/build/console-features/networking/tools/fiddler-setup-networking) est un outil utile pour afficher et déboguer votre trafic WinHTTP. Pour que Fiddler capture le trafic de votre titre, vous devez passer les indicateurs `WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY`, `WINHTTP_NO_PROXY_NAME` et `WINHTTP_NO_PROXY_BYPASS` à `WinHttpOpen`. Vous devez également appeler [XNetworkingVerifyServerCertificate](/fr/reference/networking/xnetworking/functions/xnetworkingverifyservercertificate) dans le rappel de la notification `WINHTTP_CALLBACK_STATUS_SENDING_REQUEST`. HTTP Monitor ne fonctionne pas avec les titres du Microsoft Game Development Kit (GDK). ## Documentation de référence de l'API * [Xuser (contenu de l'API)](/fr/reference/system/xuser/xuser_members) * Fonctions * [XUserGetTokenAndSignatureUtf16Async](/fr/reference/system/xuser/functions/xusergettokenandsignatureutf16async) * Structures * [XUserGetTokenAndSignatureUtf16Data](/fr/reference/system/xuser/structs/xusergettokenandsignatureutf16data) * [xnetworking (contenu de l'API)](/fr/reference/networking/xnetworking/xnetworking_members) * Fonctions * [XNetworkingQuerySecurityInformationForUrlUtf16Async](/fr/reference/networking/xnetworking/functions/xnetworkingquerysecurityinformationforurlutf16async) * [XNetworkingVerifyServerCertificate](/fr/reference/networking/xnetworking/functions/xnetworkingverifyservercertificate) * Structures * [XNetworkingSecurityInformation](/fr/reference/networking/xnetworking/structs/xnetworkingsecurityinformation) ## Voir aussi [Windows HTTP Services (WinHTTP)](https://learn.microsoft.com/windows/desktop/winhttp/winhttp-start-page) [Vue d'ensemble de XSAPI C (lien sécurisé)](https://developer.microsoft.com/games/xbox/docs/gdk/atoc-xsapi-c) [XUser](/fr/reference/system/xuser/xuser_members) [Configuration des services web dans l'Espace partenaires (article sous NDA)](/fr/services/xbox-services/fundamentals/s2s-auth-calls/custom-service-config/web-services/live-web-services) [Fiddler sur les consoles XBOX One](/fr/build/console-features/networking/tools/fiddler-setup-networking) [Vue d'ensemble des bonnes pratiques de sécurité des communications (article sous NDA)](/fr/build/game-principles/security/communication-security-overview) ## Related topics - [Vue d'ensemble de Windows & ROG XBOX Ally](/fr/paths/windows/overview.md) - [Vue d'ensemble de XBOX Series X|S](/fr/paths/series-xs/overview.md) - [Vue d'ensemble de l'accessibilité GDK](/fr/build/game-principles/accessibility/accessibility-overview.md) - [Vue d'ensemble de Godot et des moteurs communautaires](/fr/paths/community-engines/overview.md) - [Vue d'ensemble de Play Anywhere (console + PC)](/fr/paths/play-anywhere/overview.md)