La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive l'architettura alla base delle connessioni Finesse che utilizzano BOSH e come è possibile diagnosticare i problemi di connessione BOSH.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Le connessioni che utilizzano flussi bidirezionali su HTTP sincrono sono denominate BOSH.
Il protocollo XMPP (Extensible Messaging and Presence Protocol), noto anche come Jabber, è un protocollo con conservazione dello stato in un modello client-server. XMPP consente la consegna rapida di piccole parti di dati XML (Extensible Markup Language) strutturati da un'entità all'altra. XMPP/Jabber è ampiamente utilizzato nelle applicazioni di messaggistica istantanea (IM) e di presenza.
Tutte le entità XMPP sono identificate dal relativo ID Jabber (JID).
Schema di indirizzamento JID: user@domain/resource
utente |
nome utente client sul server XMPP o nome della sala riunioni |
dominio |
Nome di dominio completo (FQDN) server XMPP |
risorsa |
identificatore dell'entità/endpoint specifico dell'utente (ad esempio, laptop, smartphone e così via), identificatore di sessione o nome del nodo pubsub |
Nota: i tre componenti JID non vengono utilizzati in tutti i casi. In genere, un server viene definito semplicemente dal dominio, una sala conferenze definita da user@domain e un client da user@domain/resource.
I messaggi XMPP sono chiamati stanze. In XMPP sono disponibili tre stanze principali:
1. <message>: una direzione, un destinatario
2. <presence>: una direzione, pubblica in molte
3. <iq>: info/query - richiesta/risposta
Tutte le stanze hanno gli indirizzi di destinazione e di origine e la maggior parte delle stanze ha anche gli attributi type, id e xml:langattribute.
Attributo stanza |
Scopo |
a |
JID destinazione |
da |
JID di origine |
tipo |
scopo del messaggio |
ID |
identificatore univoco utilizzato per collegare una richiesta a una risposta per le stanze <iq> |
xml:lang |
definisce la lingua predefinita per qualsiasi file XML leggibile nella 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>
Se un'applicazione Web deve funzionare con XMPP, possono verificarsi numerosi problemi. Poiché i browser non supportano XMPP su TCP (Transmission Control Protocol) in modo nativo, tutto il traffico XMPP deve essere gestito da un programma in esecuzione all'interno del browser. I server Web e i browser comunicano tramite messaggi HTTP (HyperText Transfer Protocol), pertanto Finesse e altre applicazioni Web inseriscono i messaggi XMPP all'interno dei messaggi HTTP.
La prima difficoltà con questo approccio è che HTTP è un protocollo senza stato. Ciò significa che ogni richiesta HTTP non è correlata ad altre richieste. Tuttavia, questo problema può essere affrontato con mezzi applicativi, ad esempio tramite l'utilizzo di cookie/dati di post.
La seconda difficoltà è rappresentata dal comportamento unidirezionale di HTTP. Solo il client invia le richieste e solo il server può rispondere. L'impossibilità del server di eseguire il push dei dati rende innaturale l'implementazione di XMPP su HTTP.
Questo problema non esiste nella specifica di base XMPP originale (RFC 6120), dove XMPP è associato a TCP. Tuttavia, se si desidera risolvere il problema con XMPP associato a HTTP, ad esempio, poiché Javascript può inviare richieste HTTP, esistono due possibili soluzioni. Entrambi richiedono un bridge tra HTTP e XMPP.
Le soluzioni proposte sono:
1. Polling (protocollo legacy): richieste HTTP ripetute che richiedono nuovi dati definiti in XEP-0025: polling HTTP Jabber
2. Il polling lungo è anche noto come BOSH: protocollo di trasporto che emula la semantica di una connessione TCP bidirezionale di lunga durata tra due entità utilizzando in modo efficiente più coppie di richiesta/risposta HTTP sincrone senza richiedere l'utilizzo di polling frequenti definito in XEP-0124: Binding HTTP ed esteso da XEP-0206: XMPP Over BOSH
Finesse implementa BOSH in quanto è abbastanza efficiente dal punto di vista del carico del server e del traffico. Il motivo per utilizzare BOSH è quello di coprire il fatto che il server non deve rispondere non appena c'è una richiesta. La risposta viene posticipata fino a un tempo specificato finché il server non dispone dei dati per il client, quindi viene inviata come risposta. Non appena il client riceve la risposta, effettua una nuova richiesta e così via.
Il client desktop Finesse (applicazione Web) stabilisce una connessione BOSH non aggiornata sulla porta TCP 7443 ogni 30 secondi. Dopo 30 secondi, se non sono disponibili aggiornamenti dal servizio di notifica Finesse, il servizio di notifica invia una risposta HTTP con 200 OK e un corpo di risposta (quasi) vuoto. Se il Servizio di notifica dispone di un aggiornamento sulla presenza di un agente o di un evento di conversazione (chiamata), ad esempio, i dati vengono inviati immediatamente al client Web Finesse.
In questo esempio viene illustrata la prima risposta alla richiesta di messaggio XMPP condivisa tra il client Finesse e il server Finesse per impostare la connessione 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>
Per riepilogare:
Finesse implementa anche la specifica XMPP XEP-0060: Publish-Subscribe. Lo scopo di questa specifica è consentire al server XMPP (Servizio di notifica) di ottenere informazioni pubblicate sui nodi XMPP (argomenti) e quindi di inviare eventi XMPP alle entità sottoscritte dal nodo. Nel caso di Finesse, il server CTI (Computer Telephony Integration) invia messaggi CTI al servizio Web Finesse per comunicare a Finesse gli aggiornamenti della configurazione, quali, ma non solo, la creazione dell'agente o della coda CSQ (Contact Service Queue) o le informazioni su una chiamata. Queste informazioni vengono quindi convertite in un messaggio XMPP che il servizio Web Finesse pubblica nel servizio di notifica Finesse. Il servizio di notifica Finesse invia quindi messaggi XMPP su BOSH agli agenti che hanno sottoscritto determinati nodi XMPP.
Alcuni degli oggetti API Finesse definiti nel manuale Finesse Web Services Developer Guide sono nodi XMPP. I client Web Finesse di agenti e supervisori possono sottoscrivere aggiornamenti di eventi per alcuni di questi nodi XMPP in modo da avere informazioni aggiornate sugli eventi in tempo reale (come gli eventi chiamata, gli eventi stato e così via). Questa tabella mostra i nodi XMPP abilitati per pubsub.
Oggetto API Finesse |
Scopo |
Abbonamento |
/finesse/api/User/<IDLogo> |
Mostra la mappatura dello stato e del team dell'agente |
Agenti e supervisori |
/finesse/api/User/<IDlogin>/Dialogs |
Mostra le chiamate gestite dall'agente |
Agenti e supervisori |
/finesse/api/User/<IDlogin>/RegistroClient |
Consente di acquisire i log dei client tramite il pulsante Invia segnalazione errori |
Agenti e supervisori |
/finesse/api/User/<IDlogin>/Queue/<IDcoda> |
Mostra i dati delle statistiche di coda (se abilitati) |
Agenti e supervisori |
/finesse/api/Team/<IDTEAM>/Users |
Mostra gli agenti che appartengono a un determinato team, incluse le informazioni sullo stato |
Supervisori |
/finesse/api/SystemInfo |
Mostra lo stato del server Finesse. Utilizzato per determinare se il failover è necessario |
Agenti e supervisori |
Passaggio 1. Scaricare e installare il ping del client XMPP.
Passaggio 2. Passare a Account > Modifica > Base e configurare le opzioni di accesso:
Passaggio 3. Passare a Conti > Modifica > Avanzate e configurare:
Nota: la porta 5222 viene utilizzata solo perché i client Web Finesse possono utilizzare la porta 7443 per connettersi al servizio di notifica.
Passaggio 4. Selezionare Strumenti > Plugin e abilitare la console XMPP.
Passaggio 5. Selezionare Strumenti > Console XMPP > Console XMPP per aprire la console XMPP.
Passaggio 6. Eseguire questo messaggio <iq> per visualizzare tutti i nodi XMPP esistenti.
Ad esempio:
In un ambiente lab con due agenti e due CSQ configurati, questo output è contenuto nella risposta Finesse:
Ogni browser dispone di un insieme di strumenti di sviluppo. Nella scheda Rete degli strumenti di sviluppo vengono visualizzati i messaggi HTTP inviati e ricevuti dal client Web Finesse (browser). Ad esempio, questa immagine mostra come il client Web Finesse invia una richiesta SystemInfo che controlla ogni minuto lo stato di Finesse Tomcat come controllo di failover. Vengono inoltre visualizzati i messaggi http-bind della connessione BOSH. Il server Finesse invia una risposta entro 30 secondi se non sono presenti aggiornamenti da pubblicare sui nodi XMPP a cui è sottoscritto il client Web.
Quando si verifica una disconnessione BOSH, l'errore ha perso la connessione a {FQDN server Finesse}. Attendere che venga individuato un Finesse Server raggiungibile... viene visualizzato in un banner rosso nella parte superiore del desktop Finesse.
Questo messaggio viene visualizzato perché al momento non è possibile ricevere eventi di sottoscrizione XMPP dal servizio di notifica Cisco Finesse. Pertanto, le informazioni sullo stato e i dettagli delle chiamate non possono essere visualizzati sul desktop dell'agente.
Per UCCX, 60 secondi dopo la disconnessione del browser, l'agente viene messo in stato di disconnessione. L'agente può trovarsi nello stato Pronto o Non pronto per consentire la disconnessione.
Per UCCE, Finesse impiega fino a 120 secondi per rilevare quando un agente chiude il browser o il browser si blocca e Finesse attende 60 secondi prima di inviare una richiesta di disconnessione forzata al server CTI, che determina il server CTI a mettere l'agente in uno stato Non pronto. In queste condizioni, Finesse può impiegare fino a 180 secondi per disconnettere l'agente. A differenza di UCCX, l'agente passa allo stato Non pronto anziché allo stato Disconnessione.
Nota: il comportamento dello stato disconnessione CTI non pronta rispetto a disconnessione in UCCE è controllato dal parametro PG /LOAD. In base alle Note di rilascio per Unified Contact Center Enterprise & Hosted release 10.0(1), il parametro /LOAD è deprecato a partire da UCCE 10.0.
Per ulteriori informazioni sul comportamento di UCCE Finesse Desktop, fare riferimento alla sezione Desktop Behavior del capitolo Cisco Finesse Failover Mechanism nel manuale Cisco Finesse Administration Guide.
Nota: i valori del timer possono cambiare in futuro in base al fabbisogno del prodotto.
I registri del servizio di notifica Finesse e UCCX possono essere raccolti tramite RTMT o tramite la CLI:
file get activelog /desktop recurs compress
Nota: impostare i log del livello di debug solo durante la riproduzione di un problema. Dopo aver riprodotto il problema, disattivare i debug.
Nota: in Finesse 9.0(1) non è disponibile la registrazione a livello di debug. La registrazione a livello di debug è stata introdotta in Finesse 9.1(1). Il processo di abilitazione della registrazione è diverso in 9.1(1) rispetto a Finesse 10.0(1) - 11.6(1). Per questo processo, consultare la Guida all'amministrazione e alla manutenzione di Finesse.
Abilitare i registri di debug del Servizio di notifica di Unified Contact Center Express (UCCX), come mostrato:
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 can be disabled automatically if Cisco Unified CCX Notification Service is restarted.
Abilitare i registri di debug del servizio di notifica di Unified Contact Center Enterprise (UCCE) (Finesse Standalone), come mostrato:
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 can be disabled automatically if you restart the Cisco Finesse Notification Service
Questi registri si trovano nella cartella /desktop/logs/openfire e sono denominati debug.log.
Come mostrato nell'immagine, il file debug.log del servizio di notifica (Openfire) mostra il binding http con il desktop, l'indirizzo IP e la porta del PC dell'agente.
Come mostrato nell'immagine, gli ultimi 0 ms attivi indicano che la sessione è ancora attiva.
Openfire chiudendo la sessione inattiva indica che la disconnessione dell'agente può essere attivata in 60 secondi quando Finesse può inviare una disconnessione forzata con un codice motivo di 255 al server CTI. Il comportamento effettivo del desktop in queste condizioni dipende dall'impostazione di Disconnessione agente (LOAD) in UCCE. In UCCX, questo è sempre il comportamento.
Se il client Finesse non invia messaggi di bind http al server Finesse, i log possono mostrare il tempo di attività della sessione e la chiusura della sessione.
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>
Questi registri si trovano nella cartella /desktop/logs/openfire e sono denominati info.log. Se il client Finesse non invia messaggi di bind http al server Finesse, i log possono indicare che la sessione è diventata inattiva.
2017.06.17 00:16:04 Closing idle session (id=f382a015): 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
after inactivity for more than threshold value of 60 2017.06.17 00:16:04 A session is closed for 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
Questi registri si trovano nella cartella /desktop/logs/webservices e sono denominati Desktop-webservices.YYYY-MM-DDTHH-MM-SS.sss.log. Se il client Finesse non invia messaggi di bind http al server Finesse entro il periodo di tempo specificato, i log possono indicare che la presenza dell'agente non è più disponibile e 60 secondi dopo, può verificarsi una disconnessione basata sulla presenza.
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
Le connessioni BOSH vengono impostate dal client Web e il server Finesse determina se la presenza dell'agente non è disponibile. Si tratta quasi sempre di problemi sul lato client relativi al browser, al computer agente o alla rete, in quanto l'onere di avviare la connessione spetta al client.
Verificare i seguenti problemi:
1. Problema di rete:
Ogni minuto il client si connette al server Finesse per calcolare la deviazione e la latenza di rete:
<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
In caso di problemi di raccolta dei log, consultare il documento sulla risoluzione dei problemi di registrazione persistente di Cisco Finesse Desktop
2. Browser e/o versione non supportati:
Usa browser/versione e impostazioni supportati in base alle matrici di compatibilità:
3. Condizione di blocco del browser a causa del contenuto/elaborazione di altre schede/finestre:
Controllare il flusso di lavoro dell'agente per verificare se:
4. Computer messo in sospensione:
Verificare se l'agente mette il computer in sospensione prima di disconnettersi da Finesse o se il timer di impostazione della sospensione del computer è molto basso.
5. Problema elevato di CPU o di memoria nel computer client:
6. Gadget di terze parti che eseguono attività impreviste e problematiche in background:
Verificare il comportamento del desktop Finesse rimuovendo tutti i gadget di terze parti.
7. Problema NTP su server o client:
Verificare i seguenti problemi:
1. Disconnessione del servizio Cisco Unified Communications Manager CTIManager. Se tutti i provider CTIManager per UCCX vengono arrestati o arrestati in modo anomalo, gli agenti UCCX visualizzeranno il banner rosso. Gli agenti UCCE non vedono il banner rosso se ciò accade, ma le chiamate non riescono a indirizzare correttamente gli agenti.
Nota: i nomi dei file di dump di base utilizzano il formato: core.<ProcessID>.<SignalNumber>.<ProcessName>.<EpochTime>.
Esempio: core.24587.6.CTIManager.1533441238
Quindi, l'ora dell'incidente può essere determinata dall'ora dell'epoca.
2. Arresto o arresto anomalo del servizio di notifica Finesse/UCCX:
Riavviare Cisco Finesse Tomcat e il servizio di notifica in caso di sospetto arresto anomalo. Questa operazione è consigliata solo in caso di interruzione della rete, altrimenti questi riavviano gli agenti di disconnessione dal server Finesse.
Passaggi per UCCE:
Passaggi per UCCX:
Configurare Fiddler può essere un'attività piuttosto impegnativa senza comprendere i passaggi necessari e il funzionamento di Fiddler. Fiddler è un proxy web man-in-the-middle che si trova tra il client Finesse (browser web) e il server Finesse. A causa delle connessioni protette tra il client Finesse e il server Finesse, ciò aggiunge un livello di complessità alla configurazione del Findler per visualizzare i messaggi protetti.
Poiché Fiddler si trova tra il client Finesse e il server Finesse, l'applicazione Finesse deve creare certificati firmati per tutte le porte TCP Finesse che richiedono certificati:
Certificati di servizio Cisco Finesse Tomcat
Certificati del servizio di notifica Cisco Finesse (Unified CCX)
La decrittografia HTTPS deve essere abilitata affinché Fiddler generi dinamicamente certificati per conto del server Finesse. Questa opzione non è attivata per impostazione predefinita.
Se la decrittografia HTTPS non è configurata, viene rilevata la connessione del tunnel iniziale al servizio di notifica, ma non il traffico http-bind. Fiddler mostra solo:
Tunnel to <Finesse server FQDN>:7443
I certificati Finesse firmati da Fiddler devono quindi essere considerati attendibili dal client. Se questi certificati non sono considerati attendibili, non è possibile passare oltre la fase Stabilire una connessione crittografata... di accesso Finesse.
In alcuni casi, l'accettazione delle eccezioni del certificato dall'accesso non funziona e i certificati devono essere considerati attendibili dal browser manualmente.
Attenzione: la configurazione di esempio fornita è per Fiddler v5.0.20182.28034 per .NET 4.5 e Mozilla Firefox 64.0.2 (32 bit) su Windows 7 x64 in un ambiente lab. Queste procedure non possono essere generalizzate in tutte le versioni di Fiddler, in tutti i browser o in tutti i sistemi operativi. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dalla configurazione. Fare riferimento alla documentazione ufficiale del Finder per ulteriori informazioni.
Passaggio 1. Scarica trovatore
Passaggio 2. Abilita decrittografia HTTPS. Selezionare Strumenti > Opzioni > HTTPS e selezionare la casella di controllo Decrittografa traffico HTTPS.
Passaggio 3. Verrà visualizzata una finestra di messaggio di avviso in cui viene richiesto di confermare l'attendibilità del certificato radice del provider di servizi di individuazione. Selezionare Sì.
Passaggio 4. Viene visualizzata una finestra di messaggio di avviso con il messaggio "Si sta per installare un certificato da un'Autorità di certificazione (CA) che dichiara di rappresentare: DO_NOT_TRUST_FiddlerRoot... Installare il certificato?". Selezionare Sì.
Passaggio 5. Aggiungere manualmente i certificati di editore e sottoscrittore Finesse all'archivio certificati del computer o del browser. Verificare le porte 8445, 7443 e (solo per UCCE) 443. Ad esempio, in Firefox, è possibile eseguire questa operazione semplicemente senza scaricare i certificati dalla pagina Amministrazione del sistema operativo Finesse:
Opzioni > Trova in Opzioni (ricerca) > Certificati > Server > Aggiungi eccezione > Posizione > Immettere https://<Server Finesse>:porta per le porte rilevanti per entrambi i server Finesse.
Passaggio 6. Accedere a Finesse e vedere i messaggi http-bind lasciare il client Finesse al server Finesse tramite Fiddler.
Nell'esempio fornito, i primi 5 messaggi mostrano i messaggi http-bind a cui il server Finesse ha risposto. Il primo messaggio contiene 1571 byte di dati restituiti nel corpo del messaggio. Il corpo contiene un aggiornamento XMPP relativo a un evento agente. Il messaggio http-bind finale è stato inviato dal client Finesse, ma non ha ricevuto risposta dal server Finesse. È possibile determinare questa condizione quando il risultato HTTP è null (-) e il numero di byte nel corpo della risposta è null (-1).
Visualizzazione più dettagliata dei dati:
Corpo risposta per messaggio XMPP:
Wireshark è uno strumento comunemente usato per lo sniffing dei pacchetti che può essere usato per sniffare e decodificare il traffico HTTPS. Il traffico HTTPS è il traffico HTTP protetto tramite TLS (Transport Layer Security). TLS fornisce integrità, autenticazione e riservatezza tra due host. Viene comunemente utilizzato nelle applicazioni Web, ma può essere utilizzato con qualsiasi protocollo che utilizzi TCP come protocollo del livello trasporto. SSL (Secure Sockets Layer) è la versione precedente del protocollo TLS, che non viene più utilizzata in quanto non protetta. Questi nomi vengono spesso utilizzati in modo intercambiabile e il filtro Wireshark utilizzato per il traffico SSL o TLS è ssl.
Attenzione: la configurazione di esempio fornita è per Wireshark 2.6.6 (v2.6.6-0-gdf942cd8) e Mozilla Firefox 64.0.2 (32 bit) su Windows7 x64 in un ambiente lab. Queste procedure non possono essere generalizzate in tutte le versioni di Fiddler, in tutti i browser o in tutti i sistemi operativi. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dalla configurazione. Fare riferimento alla documentazione ufficiale di Wireshark SSL per ulteriori informazioni. Wireshark 1.6 o superiore.
Nota: questo metodo può funzionare solo per Firefox e Chrome. Questo metodo non funziona per Microsoft Edge.
Passaggio 1. Sul PC Windows dell'agente passare a Pannello di controllo > Sistema e sicurezza > Sistema > Impostazioni di sistema avanzate Variabili ambientali...
Passaggio 2. Passare a Variabili utente per utente <nomeutente> > Nuovo...
Creare una variabile denominata SSLKEYLOGFILE.
Creare un file per archiviare il segreto del premaster SSL in una directory privata: SSLKEYLOGFILE=</path/to/private/directory/with/logfile>
Nota: creare una variabile di sistema anziché una variabile utente e/o memorizzare il file in una directory non privata, ma tutti gli utenti del sistema possono accedere al segreto della premastro, che è meno sicuro.
Passaggio 3. Se Firefox o Chrome sono aperti, chiudere le applicazioni. Dopo la riapertura, possono iniziare a scrivere in SSLKEYLOGFILE.
Passaggio 4. In Wireshark, selezionare Modifica > Preferenze...
Passare a Protocolli > SSL.
Passaggio 5. Immettere il percorso del nome file del registro segreto premaster configurato nel passaggio 2.
Passaggio 6. Utilizzare Wireshark filter tcp.port==7443 && ssl, la comunicazione HTTP protetta tra il client Finesse e il server Finesse (Servizio di notifica) risulta decrittografata.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
31-May-2023 |
Titolo aggiornato, Introduzione, PII, Lingua distorta, SEO, Testo alternativo, Requisiti di personalizzazione, Requisiti di stile, Traduzione automatica, Gerund, Formattazione. |
1.0 |
23-Jun-2017 |
Versione iniziale |