Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit l'architecture derrière les connexions Finesse qui utilisent les flux bidirectionnels via HTTP synchrone (BOSH) et comment diagnostiquer les problèmes de connexion BOSH.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Le protocole XMPP (Extensible Messaging and Presence Protocol) (également appelé Jabber) est un protocole avec état dans un modèle client-serveur. XMPP permet la livraison rapide de petits morceaux de données XML (eXtensible Markup Language) structurées d'une entité à l'autre. XMPP/Jabber est largement utilisé dans les applications de messagerie instantanée et de présence.
Toutes les entités XMPP sont identifiées par leur ID Jabber (JID).
Schéma d'adressage JID : user@domain/ressource
utilisateur | nom d'utilisateur du client sur le serveur XMPP ou nom de la salle de conférence |
domaine | Nom de domaine complet (FQDN) du serveur XMPP |
ressource | identificateur de l'entité/point de terminaison spécifique de l'utilisateur (par exemple, ordinateur portable, smartphone, etc.), identificateur de session ou nom de noeud pubsub |
Note: Les trois composants JID ne sont pas utilisés dans tous les cas. Un serveur est généralement défini par le domaine, une salle de conférence définie par user@domain et un client par user@domain/resource.
Les messages XMPP sont appelés stanzas. Il existe trois normes principales dans XMPP :
1. <message> : une direction, un destinataire
2. <présence> : une direction, publier à plusieurs
3. <iq> : info/query - requête/réponse
Tous les stanzas doivent être des types, id et xml : langattribute et de la plupart des stanzas.
Attribut Stanza | Objectif |
par | JID de destination |
expéditeur | JID source |
type | objet du message |
id | identificateur unique utilisé pour lier une demande à une réponse pour <iq> stanzas |
xml:lang | définit le langage par défaut pour tout XML lisible par l'homme dans la stanza |
<message to='person1@example' from='person2@example' type='chat'>
<subject> Team meeting </subject>
<body>Hey, when is our meeting today? </body>
<thread>A4567423</thread>
</message>
Si une application Web doit fonctionner avec XMPP, plusieurs problèmes se posent. Les navigateurs ne prennent pas en charge XMPP sur TCP (Transmission Control Protocol) en mode natif, de sorte que tout le trafic XMPP doit être géré par un programme qui s'exécute à l'intérieur du navigateur. Les serveurs Web et les navigateurs communiquent via des messages HTTP (HyperText Transfer Protocol). Finesse et d'autres applications Web encapsulent donc les messages XMPP dans des messages HTTP.
La première difficulté de cette approche est que HTTP est un protocole sans état. Cela signifie que chaque requête HTTP n'est liée à aucune autre requête. Cependant, ce problème peut être résolu par des moyens applicatifs, par exemple par l'utilisation de cookies/données de poste.
La deuxième difficulté est le comportement unidirectionnel du protocole HTTP. Seul le client envoie des requêtes et le serveur ne peut répondre que. L'incapacité du serveur à transmettre des données rend l'implémentation de XMPP sur HTTP peu naturelle.
Ce problème n'existe pas dans la spécification XMPP Core d'origine (RFC 6120), où XMPP est lié à TCP. Cependant, si vous voulez résoudre le problème avec XMPP lié à HTTP, par exemple, parce que Javascript peut envoyer des requêtes HTTP, il y a deux solutions possibles. Les deux nécessitent un pont entre HTTP et XMPP.
Les solutions proposées sont les suivantes :
1. Interrogation (protocole hérité) : requêtes HTTP répétées demandant de nouvelles données définies dans XEP-0025 : Sondage HTTP Jabber
2. L'interrogation longue est également appelée BOSH : protocole de transport qui émule la sémantique d'une connexion TCP bidirectionnelle de longue durée entre deux entités en utilisant efficacement plusieurs paires de requêtes/réponses HTTP synchrones sans nécessiter l'utilisation d'interrogation fréquente définie dans XEP-0124 : Liaison HTTP et étendue par XEP-0206 : XMPP sur BOSH
Finesse implémente BOSH car il est assez efficace du point de vue de la charge du serveur et du trafic. L'utilisation du BOSH a pour but de dissimuler le fait que le serveur n'a pas à répondre dès qu'il y a une demande. La réponse est retardée jusqu'à un délai spécifié jusqu'à ce que le serveur ait des données pour le client, puis elle est envoyée en tant que réponse. Dès que le client reçoit la réponse, il fait une nouvelle demande, etc.
Le client de bureau Finesse (application Web) établit une connexion BOSH stable sur le port TCP 7443 toutes les 30 secondes. Après 30 secondes, s'il n'y a pas de mises à jour du service de notification Finesse, le service de notification envoie une réponse HTTP avec 200 OK et un corps de réponse (presque) vide. Si le service de notification dispose d'une mise à jour sur la présence d'un agent ou d'un événement de dialogue (appel), par exemple, les données sont immédiatement envoyées au client Web Finesse.
Cet exemple montre la première réponse de requête de message XMPP partagée entre le client Finesse et le serveur Finesse pour configurer la connexion BOSH.
Finesse client request:
<body xmlns="http://jabber.org/protocol/httpbind" xml:lang="en-US" xmlns:xmpp="urn:xmpp:xbosh" hold="1" ver="1.9" to="fin1.ucce.local" wait="30" xmpp:version="1.0" from="47483648@fin1.ucce.local" rid="704654808"/>
Finesse server response:
<body xmlns="http://jabber.org/protocol/httpbind" xmlns:stream="http://etherx.jabber.org/streams" authid="26779701" sid="26779701" secure="true" requests="4" inactivity="60" polling="5" wait="30" hold="1" ack="704654808" maxpause="300" ver="1.6"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features></body>
Pour récapituler :
Finesse implémente également la spécification XMPP XEP-0060 : Publier-Abonner. L'objectif de cette spécification est de permettre au serveur XMPP (service de notification) d'obtenir des informations publiées sur les noeuds XMPP (rubriques), puis d'envoyer des événements XMPP aux entités abonnées au noeud. Dans le cas de Finesse, le serveur CTI (Computer Telephony Integration) envoie des messages CTI au service Web Finesse pour informer Finesse des mises à jour de configuration telles que, mais sans s'y limiter, la création d'un agent ou d'une file d'attente de service de contact (CSQ) ou des informations relatives à un appel. Ces informations sont ensuite converties en un message XMPP que le service Web Finesse publie dans le service de notification Finesse. Le service de notification Finesse envoie ensuite des messages XMPP via BOSH aux agents qui sont abonnés à certains noeuds XMPP.
Certains des objets API Finesse définis dans le Guide de développement des services Web Finesse sont des noeuds XMPP. Les clients Web Finesse agent et superviseur peuvent s'abonner aux mises à jour d'événements pour certains de ces noeuds XMPP afin d'avoir des informations à jour sur les événements en temps réel (tels que les événements d'appel, les événements d'état, etc.). Ce tableau indique les noeuds XMPP qui sont activés par pubsub.
Objet API Finesse | Objectif | Abonnement |
/finesse/api/User/<ID de connexion> | Affiche le mappage de l'état et de l'équipe de l'agent | Agents et superviseurs |
/finesse/api/User/<LoginID>/Dialogues |
Affiche les appels traités par l'agent | Agents et superviseurs |
/finesse/api/User/<LoginID>/ClientLog |
Utilisé pour capturer les journaux du client à partir du bouton Envoyer le rapport d'erreur | Agents et superviseurs |
/finesse/api/User/<LoginID>/Queue/<queueID> |
Affiche les données des statistiques de file d'attente (si activé) | Agents et superviseurs |
/finesse/api/Team/<TeamID>/Users |
Affiche les agents qui appartiennent à une certaine équipe, y compris les informations d'état | Superviseurs |
/finesse/api/SystemInfo |
Affiche l'état du serveur Finesse. Utilisé pour déterminer si le basculement est nécessaire | Agents et superviseurs |
Étape 1. Téléchargez et installez le client XMPP Pidgin.
Étape 2. Accédez à Accounts > Modify > Basic et configurez les options de connexion :
Étape 3. Accédez à Comptes > Modifier > Avancé et configurez :
Remarque : le port 5222 est utilisé car seuls les clients Web Finesse peuvent utiliser le port 7443 pour se connecter au service de notification.
Étape 4. Accédez à Outils > Plugins et activez la console XMPP.
Étape 5. Accédez à Outils > Console XMPP > Console XMPP pour ouvrir la console XMPP.
Étape 6. Exécutez ce message <iq> pour afficher tous les noeuds XMPP qui existent.
Exemple :
Dans un environnement de travaux pratiques avec deux agents et deux CSQ configurés, ce résultat est contenu dans la réponse Finesse :
Chaque navigateur dispose d'un ensemble d'outils de développement. L'onglet Réseau des outils de développement affiche les messages HTTP envoyés et reçus par le client Web Finesse (navigateur). Par exemple, cette image montre comment le client Web Finesse envoie une requête SystemInfo qui vérifie chaque minute l'état de Finesse Tomcat comme contrôle de basculement. En outre, les messages http-bind de la connexion BOSH sont également affichés. Le serveur Finesse renvoie une réponse dans un délai de 30 secondes s'il n'y a aucune mise à jour à publier sur les noeuds XMPP auxquels le client Web est abonné.
Lorsqu'une déconnexion BOSH se produit, l'erreur « Connexion perdue à {Finesse Server FQDN}. Veuillez patienter jusqu'à ce qu'un serveur Finesse soit trouvé... » s'affiche dans une bannière rouge en haut du bureau Finesse.
Ce message s'affiche car, pour le moment, aucun événement d'abonnement XMPP ne peut être reçu du service de notification Cisco Finesse. Par conséquent, les informations d'état et les détails de l'appel ne peuvent pas être affichés sur le bureau de l'agent.
Pour UCCX, 60 secondes après la déconnexion du navigateur, l'agent est mis en état Déconnexion. L'agent peut être à l'état Prêt ou Non prêt pour la déconnexion.
Pour UCCE, Finesse met jusqu'à 120 secondes pour détecter lorsqu'un agent ferme le navigateur ou le navigateur plante et que Finesse attend 60 secondes avant d'envoyer une demande de déconnexion forcée au serveur CTI, ce qui fait que le serveur CTI met l'agent dans un état Non prêt. Dans ces conditions, Finesse peut prendre jusqu'à 180 secondes pour déconnecter l'agent. Contrairement à UCCX, l'agent passe à l'état Non prêt au lieu de l'état Déconnexion.
Note: La CTI se déconnecte Non prêt par rapport à Le comportement d'état de déconnexion dans UCCE est contrôlé par le paramètre PG /LOAD. Selon les Notes de publication pour Unified Contact Center Enterprise & Hosted Release 10.0(1), le paramètre /LOAD est déconseillé à partir de UCCE 10.0.
Pour plus d'informations sur le comportement d'UCCE Finesse Desktop, reportez-vous à la section Comportement du poste de travail du chapitre Mécanismes de basculement Cisco Finesse du Guide d'administration de Cisco Finesse.
Note: Les valeurs du temporisateur peuvent changer à l'avenir en fonction des besoins du produit.
Les journaux du service de notification Finesse et UCCX peuvent être collectés via RTMT ou via l'interface de ligne de commande :
fichier get activelog /desktop recress
Note: Définissez les journaux de niveau de débogage uniquement lors de la reproduction d'un problème. Désactivez les débogages une fois le problème reproduit.
Note: Finesse 9.0(1) n'a pas de journalisation de niveau de débogage. La journalisation du niveau de débogage a été introduite dans Finesse 9.1(1). Le processus d'activation de la journalisation est différent dans la version 9.1(1) par rapport à Finesse 10.0(1) - 11.6(1). Pour ce processus, consultez le guide Administration et convivialité Finesse.
Activez les journaux de débogage du service de notification de Unified Contact Center Express (UCCX), comme indiqué :
admin:utils uccx notification-service log enable
WARNING! Enabling Cisco Unified CCX Notification Service logging can affect system performance
and should be disabled when logging is not required.
Do you want to proceed (yes/no)? yes
Cisco Unified CCX Notification Service logging enabled successfully.
NOTE: Logging will be disabled automatically if Cisco Unified CCX Notification Service is restarted.
Activez les journaux de débogage du service de notification de Unified Contact Center Enterprise (UCCE) (Finesse Standalone), comme indiqué :
admin:utils finesse notification logging enable
Checking that the Cisco Finesse Notification Service is started...
The Cisco Finesse Notification Service is started.
Cisco Finesse Notification Service logging is now enabled.
WARNING! Cisco Finesse Notification Service logging can affect system performance
and should be disabled when logging is not required.
Note: Logging will be disabled automatically if you restart the Cisco Finesse Notification Service
Ces journaux se trouvent dans le dossier /desktop/logs/openfire et sont nommés debug.log.
Comme le montre l'image, le service de notification (Openfire) debug.log affiche la liaison http avec le bureau ainsi que l'adresse IP et le port du PC de l'agent.
Comme l'illustre l'image, la dernière valeur active de 0 ms indique que la session est toujours active.
Openfire fermant la session inactive indique que la déconnexion de l'agent se déclenchera dans 60 secondes où Finesse enverra une déconnexion forcée avec un code de raison de 255 au serveur CTI. Le comportement réel du bureau dans ces conditions dépend du paramètre Déconnexion sur déconnexion de l'agent (LOAD) dans UCCE. Dans UCCX, c'est toujours le comportement.
Si le client finlandais n'envoie pas de messages http-bind au serveur Finesse, les journaux affichent le temps d'ouverture de la session et indiquent la fermeture de la session.
2017.06.17 00:14:34 Session (id=f382a015) was last active 0 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:04 Session (id=f382a015) was last active 13230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:34 Session (id=f382a015) was last active 43230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:16:04 Session (id=f382a015) was last active 63231 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:17:04 Unable to route packet. No session is available so store offline. <message from="pubsub. xxxxx.xxxx.xxx.cisco. com" to="1001003@xxxxx.xxxx.xxx.cisco.com.cisco.com" id="/finesse/api/User/1001003__1001003@xxxxx.xxxx.xxx.cisco.com__o5Aqb"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="/finesse/api/User/1001003"><item id="0d78a283-466d-4477-a07e-6e33a856fce388"><notification xmlns="http://jabber.org/protocol/pubsub"><Update>
Ces journaux se trouvent dans le dossier /desktop/logs/openfire et sont nommés info.log. Si le client Finese n'envoie pas de messages http-bind au serveur Finesse, les journaux indiquent que la session devient inactive.
2017.06.17 00:16:04 Closing idle session (id=f382a015): 1001003@xxxxx.xxxx.xxx. cisco.com/desktop after being inactive for more than threshold value of 60 2017.06.17 00:16:04 A session is being closed for 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
Ces journaux se trouvent dans le dossier /desktop/logs/webservices et sont nommés Desktop-webservices.YYY-MM-DDTHH-MM-SS.sss.log. Si le client finlandais n'envoie pas de messages http-bind au serveur Finesse dans le délai spécifié, les journaux indiquent que la présence de l'agent devient indisponible et 60 secondes plus tard, une déconnexion déclenchée par la présence se produit.
0000001043: XX.XX.XX.XXX: Jun 17 2017 00:16:04.630 +0530: %CCBU_Smack Listener Processor (1)-6-PRESENCE_NOTIFICATION_RECIEVED: %[FROM JID=1001003@xxxxx.xxxx.xxx.cisco.com/desktop][PRESENCE_TYPE=unavailable]:Finesse received a presence notifcation 0000000417: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-UNSUBSCRIBE_REQUEST_SUCCESS: %[NodeId=/finesse/api/User/1001003/ClientLog][user_id=1001003@xxxxx.xxxx.xxx.cisco.com]: Sucessfully unsubscribed from a node on the XMPP server 0000001044: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-AGENT_PRESENCE_MONITOR: %[message_string=Adding agent 1001003 into the expiry hash.]: 0000001051: XX.XX.XX.XXX: Jun 17 2017 00:16:35.384 +0530: %CCBU_pool-8-thread-1-6-AGENT_PRESENCE_MONITOR: %[message_string=[Expired] Removed agent from cache 1001003]: 0000001060: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.632 +0530: %CCBU_CoreImpl-worker12-6-PRESENCE DRIVEN LOGOUT: %[agent_id=1001003]: Performing CTI Logout on basis of the agents unavailable presence 0000001061: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.633 +0530: %CCBU_CoreImpl-worker12-6-MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :39 , agentstate : 1, workmode : 0, reason code: 255, forceflag :1, agentcapacity: 1, agentext: 1001003, agentid: 1001003, supervisorid: null, ssoFlag=false][cti_message_name=SetAgentStateReq]: Message going to the backend cti server 0000001066: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.643 +0530: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=1 (LOGOUT), stateDuration=0, skillGroupNumber=-1, skillGroupPriority=0, agentState=1 (LOGOUT), eventReasonCode=255, numFltSkillGroups=0, CTIClientSignature=null, agentID=1001003, agentExtension=1001003, agentInstrument=null, agentID_Long=1001003, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[], MRDId=1, agentMode=0]CTIMessageBean [invokeID=null, cti_sequence_id=105, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1497638824642,"CTI_MSG_DISPATCH":1497638824643}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=1][dispatch_phase=DnD-CHECKPOINT-3B]: Decoded Message to Finesse from backend cti server
Les connexions BOSH sont configurées par le client Web et le serveur Finesse détermine si la présence de l'agent n'est pas disponible. Ces problèmes sont presque toujours des problèmes côté client liés au navigateur, à l'ordinateur de l'agent ou au réseau, car c'est au client qu'il incombe de démarrer la connexion.
Vérifiez ces problèmes :
1. Problème réseau :
Chaque minute, le client se connecte au serveur Finesse pour calculer la dérive et la latence du réseau :
<PC date-time with GMT offset>: : <Finesse FQDN>: <Finesse server date-time with offset>: Header : Client: <date-time>, Server: <date-time>, Drift: <drift> ms, Network Latency (round trip): <RTT> ms
2019-01-11T12:24:14.586 -05:00: : fin1.ucce.local: Jan 11 2019 11:24:14.577 -0600: Header : Client: 2019-01-1
2. Navigateur et/ou version non pris en charge :
Utilisez le navigateur/la version et les paramètres pris en charge conformément aux matrices de compatibilité :
3. Condition bloquée par le navigateur en raison du contenu/du traitement d'autres onglets/fenêtres :
Vérifiez le workflow de l'agent pour voir s'il :
4. Ordinateur mis en veille :
Vérifiez si l'agent met son ordinateur en veille avant de se déconnecter de Finesse ou si le compteur de mise en veille de son ordinateur est très faible.
5. Problème de CPU élevé ou de mémoire élevée sur l'ordinateur client :
6. Gadgets tiers réalisant une activité inattendue et problématique en arrière-plan :
Testez le comportement du bureau Finesse en supprimant tous les gadgets tiers.
7. Problème NTP sur le serveur ou le client :
Vérifiez ces problèmes :
1. Déconnexion du service Cisco Unified Communications Manager CTIManager. Si tous les fournisseurs CTIManager pour UCCX sont arrêtés ou interrompus, les agents UCCX voient l'erreur de bannière rouge. Les agents UCCE ne voient pas la bannière rouge si cela se produit, mais les appels ne parviennent pas à se diriger correctement vers les agents.
Remarque : les noms de fichiers de vidage principaux utilisent le format core.<ProcessID>.<SignalNumber>.<ProcessName>.<EpochTime>.
Exemple : core.24587.6.CTIManager.1533441238
Par conséquent, l'heure de l'écrasement peut être déterminée à partir de l'époque.
2. Service de notification Finesse/UCCX arrêté ou bloqué :
Redémarrez Cisco Finesse Tomcat et le service de notification si un plantage est suspecté. Ceci est recommandé uniquement en cas de panne du réseau, sinon, ces redémarrages déconnectent les agents du serveur Finesse.
La configuration de Fiddler peut s’avérer difficile sans comprendre les étapes nécessaires et comprendre le fonctionnement de Fiddler. Fiddler est un proxy web man-in-the-Middle qui se trouve entre le client Finesse (navigateur web) et le serveur Finesse. En raison des connexions sécurisées entre le client Finesse et le serveur Finesse, cela ajoute une couche de complexité à la configuration Fiddler afin d'afficher les messages sécurisés.
Puisque Fiddler se trouve entre le client Finesse et le serveur Finesse, l'application Fiddler doit créer des certificats signés pour tous les ports TCP Finesse nécessitant des certificats :
Certificats de service Cisco Finesse Tomcat
Certificats de service de notification Cisco Finesse (Unified CCX)
Le déchiffrement HTTPS doit être activé pour que Fiddler génère dynamiquement des certificats pour le compte du serveur Finesse. Cette option n'est pas activée par défaut.
Si le déchiffrement HTTPS n'est pas configuré, la connexion initiale au tunnel au service de notification est visible, mais le trafic http-bind ne l'est pas. Fiddler affiche uniquement :
Tunnel to <Finesse server FQDN>:7443
Ensuite, les certificats Finesse signés par Fiddler doivent être approuvés par le client. Si ces certificats ne sont pas fiables, passez à l'étape Établissement d'une connexion chiffrée... étape de connexion Finesse n'est pas possible.
Dans certains cas, l'acceptation des exceptions de certificat de la connexion ne fonctionne pas et les certificats doivent être approuvés manuellement par le navigateur.
Attention : L'exemple de configuration fourni concerne Fiddler v5.0.20182.28034 pour .NET 4.5et Mozilla Firefox 64.0.2 (32 bits) sur Windows 7 x64 dans un environnement de travaux pratiques. Ces procédures peuvent ne pas être généralisées à toutes les versions de Fiddler, à tous les navigateurs ou à tous les systèmes d'exploitation des ordinateurs. Si votre réseau est actif, assurez-vous de bien comprendre l'impact potentiel de toute configuration. Consultez la documentation officielle de Fiddler pour plus de renseignements.
Étape 1. Télécharger Fiddler
Étape 2. Activer le déchiffrement HTTPS : Outils > Options > HTTPS > cochez la case Décrypter le trafic HTTPS
Étape 3. Une boîte de message d'avertissement s'ouvre pour demander à d'approuver le certificat racine Fiddler. Sélectionnez Oui.
Étape 4. Une boîte de message d'avertissement s'ouvre avec le message « Vous êtes sur le point d'installer un certificat d'une autorité de certification (CA) prétendant représenter : DO_NOT_TRUST_FiddlerRoot... Voulez-vous installer ce certificat ? ». Sélectionnez Oui.
Étape 5. Ajoutez manuellement les certificats d'éditeur et d'abonné Finesse au magasin d'approbation des certificats de l'ordinateur ou du navigateur. Vérifiez les ports 8445, 7443 et (uniquement pour UCCE) 443. Par exemple, sur Firefox, cela peut être fait simplement sans télécharger les certificats à partir de la page d'administration du système d'exploitation Finesse :
Options > Find in Options (search) > Certificates > Servers > Add Exception > Location > Enter https://<Finesse server>:port for the appropriés ports for the two Finesse servers.
Étape 6. Connectez-vous à Finesse et consultez les messages http-bind qui laissent le client Finesse au serveur Finesse via Fiddler.
Dans l'exemple fourni, les 5 premiers messages affichent des messages http-bind auxquels le serveur Finesse a répondu. Le premier message contient 1 571 octets de données renvoyés dans le corps du message. Le corps contient une mise à jour XMPP concernant un événement d'agent. Le dernier message http-bind a été envoyé par le client Finesse, mais n'a pas reçu de réponse du serveur Finesse. Cela peut être déterminé en constatant que le résultat HTTP est null (-) et que le nombre d'octets dans le corps de réponse est null (-1).
Vue plus précise des données :
Corps de réponse du message XMPP :
Wireshark est un outil de détection de paquets couramment utilisé qui peut être utilisé pour détecter et décoder le trafic HTTPS. Le trafic HTTPS est le trafic HTTP sécurisé par le biais de la sécurité de la couche de transport (TLS). TLS assure l’intégrité, l’authentification et la confidentialité entre les hôtes. Il est couramment utilisé dans les applications Web, mais il peut être utilisé avec n’importe quel protocole qui utilise TCP comme protocole de couche transport. SSL (Secure Sockets Layer) est l'ancienne version du protocole TLS, qui n'est plus utilisé car il n'est pas sécurisé. Ces noms sont souvent utilisés de manière interchangeable, et le filtre Wireshark utilisé pour le trafic SSL ou TLS est ssl.
Attention : L'exemple de configuration fourni concerne Wireshark 2.6.6 (v2.6.6-0-gdf942cd8) et Mozilla Firefox 64.0.2 (32 bits) sur Windows7 x64 dans un environnement de travaux pratiques. Ces procédures peuvent ne pas être généralisées à toutes les versions de Fiddler, à tous les navigateurs ou à tous les systèmes d'exploitation des ordinateurs. Si votre réseau est actif, assurez-vous de bien comprendre l'impact potentiel de toute configuration. Consultez la documentation officielle de Wireshark SSL pour plus d'informations. Wireshark 1.6 ou supérieur est requis.
Note : Cette méthode ne fonctionnera que pour Firefox et Chrome. Cette méthode ne fonctionne pas pour Internet Explorer.
Étape 1. Sur le PC Windows de l'agent, accédez à Panneau de configuration > Système et sécurité > Système > Paramètres système avancés Variables environnementales...
Étape 2. Accédez à Variables utilisateur pour l'utilisateur <nom d'utilisateur> > Nouveau...
Créez une variable nommée SSLKEYLOGFILE.
Créez un fichier pour stocker le secret du maître SSL dans un répertoire privé : SSLKEYLOGFILE=</path/to/private/directory/with/logfile>
Note: La création d'une variable système au lieu d'une variable utilisateur et/ou le stockage du fichier dans un répertoire non privé fonctionnera également, mais tous les utilisateurs du système peuvent alors accéder au secret de prémaître, qui est moins sécurisé.
Étape 3. Si Firefox ou Chrome sont ouverts, fermez les applications. Après leur réouverture, ils commenceront à écrire dans le fichier SSLKEYLOGFILE.
Étape 4. Sur Wireshark, accédez à Edition > Préférences...
Accédez à Protocoles > SSL.
Étape 5. Entrez l'emplacement du nom de fichier journal secret du maître configuré à l'étape 2.
Étape 6. En utilisant le filtre Wireshark tcp.port==7443 && ssl, la communication HTTP sécurisée entre le client Finesse et le serveur Finesse (service de notification) est vue déchiffrée.