Comprendre et dépanner les journaux HAR pour WxCalling

Introduction

Ce document décrit la compréhension et le dépannage des journaux HAR.

Présentation des fonctionnalités

Un journal HAR (abréviation de HTTP Archive Logging) est un journal de toute l'activité réseau entre votre navigateur et un site Web au cours d'une session spécifique.

Lorsque vous visitez un site Web, votre navigateur envoie des requêtes au serveur et reçoit des réponses. Le fichier HAR capture toutes ces demandes, réponses et informations de synchronisation.

Ils sont essentiels pour diagnostiquer les problèmes de performances Web, dépanner les erreurs réseau et analyser les transactions d'API.

Les journaux HAR permettent d'identifier les ressources à chargement lent, les requêtes ayant échoué et de suivre les interactions des utilisateurs avec les applications Web.

Limites

• Les fichiers HAR peuvent être volumineux et difficiles à analyser manuellement.
• Les données sensibles peuvent être consignées ; assurer la désinfection des données avant le partage.
• Certaines stratégies de sécurité peuvent bloquer la capture HAR complète.

Mise en garde : Le fichier HAR inclut l'intégralité du contenu des demandes et des réponses en texte clair (y compris les mots de passe, l'ID de session, les cookies, etc.). Par conséquent, vous ne devez pas partager un fichier HAR pris dans une session avec un service disponible publiquement. Si l'onglet Réseau a été ouvert lors de la saisie d'un mot de passe, il est en texte clair dans le fichier HAR. Vous souhaitez supprimer ces informations d'identification avant de partager le fichier HAR. Ouvrez le fichier HAR enregistré dans un éditeur de texte, recherchez le mot de passe et remplacez-le par un texte aléatoire comme « ». Ne modifiez pas la mise en forme JSON du fichier lors de cette modification, car il n'est pas analysé correctement pour révision.

Outil d'assainissement HAR

Historique

En 2023, Okta a été victime d'une faille de sécurité lors du vol de fichiers HAR de ses systèmes de gestion des dossiers d'assistance. Les pirates ont utilisé le jeton d'accès et les cookies de ces fichiers pour accéder à leurs comptes clients. En réponse, Okta a mis en oeuvre un outil de désinfection.

État Actuel

Actuellement, une automatisation continue est en place qui tente de supprimer les matériaux sensibles des traces, mais laisse le reste intact pour préserver la capacité à dépanner et analyser votre problème.

Lorsque vous téléchargez un fichier HAR, l'outil effectue automatiquement les opérations suivantes :

1. Détecte qu'un fichier HAR a été téléchargé
2. Assure la désinfection du fichier HAR à l'aide de https://har-sanitize.cisco.com
3. Télécharge le fichier nettoyé dans le dossier
4. Chiffre le fichier HAR d'origine à l'aide de GPG
5. Télécharge le fichier HAR chiffré sur le boîtier
6. Supprime le fichier HAR d'origine du dossier
7. Ajoute une note au dossier expliquant ce qui a été fait et un lien vers cet outil

Remarque : Si vous ne pouvez pas résoudre le problème en utilisant la version nettoyée du fichier HAR, vous pouvez déposer une exception comme expliqué dans les sections suivantes et récupérer une copie du fichier HAR d'origine.

Comment extraire le journal HAR

Générer un fichier HAR dans votre navigateur

Reportez-vous à : Générez un fichier HAR dans votre navigateur.

Extrait du document :

• Chrome :
  Ouvrez Outils de développement (F12) > Onglet Réseau > Conserver le journal > Démarrer l'enregistrement > Reproduire le problème > Exporter le fichier HAR.
• Firefox :
  Ouvrez Outils de développement (F12) > Onglet Réseau > Icône du moteur > Cochez la case « Persist Logs » > Start Recording > Save HAR.

Informations utiles avant d'analyser les journaux HAR

Méthodes HTTP

Les méthodes HTTP (également appelées verbes HTTP) définissent le type d'opération qu'un client souhaite effectuer sur une ressource donnée (par exemple, des données ou une page Web).

Chaque méthode a une finalité et une sémantique spécifiques.

Les méthodes HTTP les plus courantes sont les suivantes : GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS et TRACE.

* PATCH est généralement idempotent, mais il dépend de la mise en oeuvre.

Explication des colonnes

• Sûr : indique si la méthode HTTP est considérée comme sûre, ce qui signifie qu'elle ne modifie pas les ressources ou l'état du serveur. Les méthodes sûres sont uniquement destinées à la récupération et non à la modification. Ils sont généralement utilisés pour les opérations en lecture seule.
• Idempotent : indique si la répétition de la même requête HTTP plusieurs fois a le même effet que sa répétition une fois. Une méthode idempotent signifie que, quel que soit le nombre de répétitions de la requête, le résultat reste inchangé (après la première requête réussie)
• Utilisation type : décrit l'objectif ou le scénario commun pour lequel la méthode HTTP est utilisée. Cela donne un contexte pour le moment et la raison pour lesquels vous utiliseriez chaque méthode dans le développement Web ou la conception d'API.
• Request Body : indique si la requête HTTP inclut généralement un corps (données envoyées au serveur). Le corps de la demande est souvent utilisé pour envoyer des données (telles que JSON, XML, données de formulaire) au serveur, par exemple lors de la création ou de la mise à jour de ressources. 
• Corps de la réponse : indique si la réponse HTTP contient généralement un corps (données renvoyées par le serveur). Le corps de la réponse correspond aux données renvoyées par le serveur au client, telles que la ressource demandée, les messages d'état ou la confirmation d'une action.

Anatomie d'un journal HAR

Remarque : Toutes les images d'exemple de cette section ont été prises lors de la tentative de chargement des emplacements dans Control HUB pour une organisation

Header (En-tête) 

Capture les métadonnées échangées entre le client (navigateur) et le serveur pendant les requêtes et les réponses HTTP.

Les en-têtes fournissent le contexte des données envoyées ou reçues, comme le type de contenu, les informations d'authentification, les stratégies de mise en cache, etc.

Les en-têtes sont inclus dans les sections suivantes d'un journal HAR :

1. En-têtes de demande : Ils sont envoyés du navigateur (client) au serveur dans le cadre de la requête HTTP.
2. En-têtes de réponse : Ils sont renvoyés par le serveur au navigateur en réponse à la demande.

Les en-têtes sont stockés sous forme de tableaux de paires clé-valeur, où :

• Clé : Nom de l'en-tête.
• Valeur: Valeur associée à l'en-tête.

En-têtes de demande communs

1. Hôte : Spécifie le nom de domaine du serveur (par exemple, as example.com) et le numéro de port.

• Exemple : Hôte : www.example.com

2. User-Agent : Identifie le navigateur ou le client à l'origine de la demande, ainsi que sa version et son système d'exploitation.

• Exemple : User-Agent : Mozilla/5.0 \(Windows NT 10.0 ; Win64 ; x64\)

3. Accepter : Indique les types de contenu que le client peut gérer (HTML, JSON, images, etc.).

• Exemple : Accepter : text/html,application/xhtml+xml

4. Accept-Encoding : Spécifie les types de codage (tels que gzip, deflate) que le client peut décoder.

• Exemple : Accept-Encoding : gzip, dégonfler

5. Autorisation : Contient des informations d'identification pour l'authentification, telles que des jetons ou des informations d'authentification de base.

• Exemple : Autorisation : Bearer <jeton>

6. Cookies : Inclut les cookies envoyés par le client au serveur.

• Exemple : Cookie : sessionId=12345 ; userPref=ModeObscur

7. Type de contenu : Indique le type de données envoyées dans le corps de la demande (pour les demandes POST/PUT).

• Exemple : Content-Type : application/json

8. Référent : Identifie l'URL de la page qui a référencé le client vers la ressource actuelle.

• Exemple : Référent : https://www.example.com/

En-têtes de réponse communs

1.Content-Type : Spécifie le type MIME de la ressource (tel que text/html, application/json).

• Exemple : Content-Type : application/json

2. Content-Length : Indique la taille du corps de la réponse en octets.

• Exemple : Content-Length : 1234

3. Contrôle du cache : Spécifie les stratégies de mise en cache pour la ressource (par exemple, si elle peut être mise en cache et pendant combien de temps).

• Exemple : Cache-Control : no-cache, no-store, must-revalidate

4. Serveur : Identifie le logiciel/la version du serveur.

• Exemple : Serveur : Apache/2.4.29

5. Set-Cookie : Contient des cookies que le serveur souhaite que le client stocke.

• Exemple : Set-Cookie : sessionId=67890 ; Chemin=/; Sécurisé 

6. Date : Date et heure auxquelles le serveur a généré la réponse.

• Exemple : Date : Mardi, 10 octobre 2023 12:00:00 GMT

7. Lieu : Utilisé dans les redirections, indiquant l'URL vers laquelle le client doit naviguer.

• Exemple : Emplacement : https://www.example.com/new-page

8. ETag : Identificateur unique de la ressource, souvent utilisé pour la mise en cache et le contrôle de version.

• Exemple : ETag : 12345abcd

9. Codage du contenu : Indique le mode de codage du corps de la réponse (par exemple, gzip, flate).

• Exemple : Encodage de contenu : gzip

10. Access-Control-Allow-Origin : Spécifie les origines autorisées à accéder aux ressources (utilisées dans CORS).

• Exemple : Access-Control-Allow-Origin : *

Remarque : L'en-tête Trackingid est le plus pertinent pour les appels Webex, car il s'agit de l'ID que vous pouvez rechercher dans l'outil LMA.

Charge Utile

Données envoyées ou reçues dans le corps d'une requête ou d'une réponse HTTP.

Il est généralement associé aux requêtes POST, PUT ou PATCH, où le client envoie des données au serveur, telles que les envois de formulaires, les téléchargements de fichiers ou les données JSON pour les API.

La charge utile peut également exister dans les réponses HTTP, qui contiennent des données renvoyées par le serveur, telles que du contenu HTML, JSON ou binaire (telles que des images, des fichiers).

Emplacement de la charge utile dans les journaux HAR

La charge utile se trouve généralement dans deux sections principales du journal HAR :

1. Demande de données utiles : Données envoyées du client (navigateur) au serveur dans le corps d'une requête HTTP.
2. Charge utile de réponse : Données renvoyées par le serveur au client dans le corps d'une réponse HTTP.

Aperçu

Fait partie de l'objet response.content et fournit une représentation des données renvoyées par le serveur dans un format structuré et lisible par l'utilisateur, le cas échéant.

L'aperçu est généralement utilisé pour afficher des données analysées ou structurées à partir du corps de réponse d'une manière conviviale, telle que JSON, XML ou d'autres formats.

Cette section est particulièrement utile pour déboguer des API, inspecter les données renvoyées ou comprendre la structure de la réponse du serveur.

Réponse

La réponse fournit des informations détaillées sur la réponse HTTP envoyée par le serveur au client (navigateur) pour une demande spécifique. Cette section contient des métadonnées, des en-têtes, des détails de contenu et d'autres données critiques qui peuvent vous aider à comprendre le comportement du serveur pendant le cycle demande-réponse. Il fournit un instantané détaillé de la réponse du serveur à une requête HTTP.

Initiateur

L'initiateur fournit des informations sur ce qui a déclenché une requête HTTP spécifique lors du chargement d'une page Web. Il identifie la source ou la cause d'une requête réseau, aidant ainsi les développeurs à comprendre la chaîne d'événements qui a conduit à la requête. L'initiateur aide également à retracer l'origine d'une requête et peut pointer vers la ligne exacte de code ou la ressource responsable de sa création.

Synchronisation

Le minutage fournit une répartition détaillée des différentes étapes impliquées dans le traitement d'une requête et d'une réponse HTTP. Il aide les développeurs à comprendre le temps nécessaire à chaque étape du cycle requête-réponse, depuis le lancement de la connexion jusqu'à la réception de la réponse finale. La synchronisation suit également la séquence et la durée des événements qui se produisent lorsqu'un navigateur envoie une requête à un serveur et reçoit une réponse. Elle inclut des mesures détaillées pour la résolution DNS, l'établissement de la connexion, l'envoi de la requête, l'attente de la réponse du serveur et le téléchargement des données de réponse.

Dépannage

Outil interne pour afficher les journaux HAR

Accédez à EasyLmaSearch > Importer le fichier HAR/Saz.

Étapes générales de dépannage

1. Ouvrez le fichier HAR dans un .
2. Identifiez les requêtes ayant échoué (telles que les erreurs HTTP 4xx/5xx).

3. Vérifiez les temps de réponse et les éléments à chargement lent.

4. Analysez les en-têtes de requête/réponse pour les problèmes d'authentification et de CORS.

5. Recherchez les ID de suivi dans les requêtes réseau et .
6. Si possible, recoupez les échecs avec les réponses.

Exemple de dépannage à partir des tickets

Éléments à charge lente

Exemple :

• Le chargement des numéros d'un emplacement par le concentrateur de contrôle prend beaucoup de temps

Dépannage :

• Demander une vidéo du problème (tentative de chargement de la page de numéros d'un site)
• Demander un journal HAR lors de la tentative de chargement des numéros d'un emplacement

1. Ouvrez le fichier HAR dans un visualiseur HAR ou dans les Outils de développement du navigateur.
   
2. Identifier la demande dans la cascade vue
   
3. Cliquez sur la requête dont le chargement prend du temps.
4. Consultez l'onglet Timing du journal :

5. Vérifiez les temps de réponse et les éléments à chargement lent.

6. Recueillez l'ID de suivi pour cet en-tête.

7. Ouvrez EasyLMA et effectuez une recherche avec le trackingid.

Expliquer les phases de répartition temporelle

Voici plus d'informations sur chacune des phases que vous pouvez voir dans l'onglet Timing :

• Mise en file. Le navigateur met en file d'attente les demandes avant le début de la connexion et lorsque :
  • Il existe des demandes de priorité plus élevée. La priorité de la demande est déterminée par des facteurs tels que le type d'une ressource, ainsi que son emplacement dans le document. Pour plus d'informations, lisez la section priorité des ressources du guide fetchpriority.
  • Il y a déjà six connexions TCP ouvertes pour cette origine, ce qui est la limite. (S'applique uniquement à HTTP/1.0 et HTTP/1.1.)
  • Le navigateur alloue brièvement de l'espace dans le cache disque.
• Bloqué. La requête peut être bloquée après le démarrage de la connexion pour l'une des raisons décrites dans Mise en file d'attente.
• Recherche DNS. Le navigateur résout l'adresse IP de la demande.
• Connexion initiale. Le navigateur établit une connexion, y compris des échanges TCP ou de nouvelles tentatives et négocie un protocole SSL.
• Négociation proxy. Le navigateur négocie la demande avec un serveur proxy.
• Demande envoyée. La demande est en cours d'envoi.
• Préparation de ServiceWorker. Le navigateur démarre l'agent de service.
• Demande adressée à ServiceWorker. La demande est envoyée au travailleur du service.
• En attente (TFB). Le navigateur attend le premier octet d'une réponse. TTFB signifie Time To First Byte. Cette durée inclut un aller-retour de latence et le temps nécessaire au serveur pour préparer la réponse.
• Téléchargement de contenu. Le navigateur reçoit la réponse, soit directement du réseau, soit d'un employé du service. Cette valeur correspond au temps total passé à lire le corps de la réponse. Des valeurs plus élevées que prévu peuvent indiquer un réseau lent ou que le navigateur est occupé à effectuer d’autres tâches qui retardent la lecture de la réponse.

Ressource non disponible

Exemple : 

« J'ai activé le NUJ pour mon utilisateur sur le concentrateur de contrôle d'administration, mais je ne vois pas l'option de configuration du numéro NUJ lorsque je me connecte au portail user.webex.com.
Pourriez-vous vérifier mon organisation et mon utilisateur pour voir pourquoi je ne peux pas le voir sur le concentrateur d'utilisateurs ?"

Dépannage :

1. Confirmez ce que l'utilisateur voit en demandant une capture d'écran d'un utilisateur actif par rapport à un utilisateur inactif.

2. Demandez un journal HAR lors du chargement des options pour l'utilisateur.

Étapes suivantes :

1. Ouvrez le fichier HAR dans un visualiseur HAR ou dans les Outils de développement du navigateur. 
   
2. Identifier les demandes :

Le service fait une demande (GET) pour connaître les services de l'utilisateur

Appel de la demande de modèle d'accès aux fonctionnalités de l'utilisateur final (GET) le modèle des services présentés à l'utilisateur :

1. Analyser les en-têtes de requête/réponse.
   
   L'option « Aucun accès » signifie que le modèle masque ces options pour l'utilisateur.
2. Vous devez revoir le modèle pour l'ORG et activer le numéro unique d'appel pour que l'utilisateur puisse le voir dans le User Hub.

Exemple :

Impossible d'activer une fonctionnalité

Exemple d'enregistrement d'appel :

Lorsque vous essayez d'activer l'enregistrement des appels pour un utilisateur, vous recevez un message d'erreur : "Echec de la modification de l'enregistrement des appels".

Pour résoudre les problèmes :

1. Confirmez l'erreur en demandant le texte complet du message d'erreur.

2. Demandez une capture d'écran de l'erreur.

3. Demandez un journal HAR tout en essayant d'activer "Enregistrement d'appel" dans l'utilisateur affecté .

4. Ouvrez le fichier HAR dans un visualiseur HAR ou dans les Outils de développement du navigateur.

5. Identifiez les requêtes ayant échoué (telles que les erreurs HTTP 4xx/5xx).

6. Recherchez les ID de suivi dans EasyLMA.


7. Avec l'exception cpapi, vous pouvez ouvrir un BEMS :

8. Ouvrez un BEMS avec les informations collectées :

• Captures d'écran
• Message d'erreur complet
• ID de suivi
• Exception cpapi
  
  

9. Demandez dans l'espace Dubber ou à l'équipe BU de vérifier avec l'équipe Dubber l'erreur :
"Résumé de la réponse aux erreurs : 400: Produit non valide : Échec de la création du point de duplication dans Dubber. État HTTP : 502"

Messagerie de télécopie

Voici le diagramme illustrant le flux de provisionnement lors de son passage dans les microservices :

Lors du dépannage des problèmes de mise en service de la messagerie de télécopie au sein du Control Hub, il est essentiel de collecter une trace HAR pour obtenir des informations détaillées sur la nature du problème et comprendre les raisons des échecs de mise en service. 

Lors de l'activation de la fonctionnalité de messagerie de télécopie, le suivi HAR capture et affiche la requête appropriée de CH vers CPAPI. Cette requête capturée suit un format spécifique.

De l'ICPP du CH → :

PATCH
URL de la demande : https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail
ID de suivi ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Publier les données {
"activé" : vrai,
"notifications" : {
"activé" : vrai,
"destination" : "lazoclaudiafi+faxmessaging@gmail.com"
},
"sendAllCalls" : {
"activé" : falsifié
},
"sendBusyCalls" : {
"activé" : vrai,
"salutation" : "PAR DÉFAUT"
},
"sendUnanswerCalls" : {
"activé" : vrai,
"salutation" : "PAR DÉFAUT",
"maxRings" : 3
},
"transferToNumber" : {
"activé" : falsifié
},
"emailCopyOfMessage" : {
"activé" : vrai,
"IDe-mail" : "lazoclaudiafi+faxmessaging@gmail.com"
},
"faxMessage" : {
"activé" : faux,
"phoneNumber" : "+12099193323",
"poste" : null
},
"messageStorage" : {
"mwiEnabled" : vrai,
"storageType" : "INTERNE",
"externalEmail" : "lazoclaudiafi+faxmessaging@gmail.com"
}

Pour effectuer un suivi efficace de ces informations dans EasyLMA, reportez-vous aux instructions détaillées fournies ici : 

Catégorie : TrackingID
Sous-catégorie : Global
ID de suivi Webex : ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Informations de remontée

• Fichier journal HAR
• Captures d'écran des erreurs
• Étapes de reproduction du problème
• Horodatage de l'incident
• Journaux LMA

Veuillez répondre à ces questions avant d'ouvrir le traitement prioritaire BEMS, car cela vous aidera à résoudre les problèmes suivants :

• Quelle erreur voyez-vous ?
• Quels identifiants de suivi voyez-vous ?
• Avez-vous vérifié l'ID de suivi dans LMA ?
• Que voyez-vous dans LMA ?
• Ce système BEMS est-il vraiment nécessaire ?