Comprendere e risolvere i problemi relativi ai registri HAR per WxCalling

Introduzione

In questo documento viene descritto come comprendere e risolvere i problemi relativi ai registri HAR.

Panoramica delle funzionalità

Un registro HAR (abbreviazione di registrazione dell'archivio HTTP) è un registro di tutte le attività di rete tra il browser e un sito Web durante una sessione specifica.

Quando si visita un sito Web, il browser invia le richieste al server e riceve le risposte. Il file HAR acquisisce tutte le richieste, le risposte e le informazioni sulla tempistica.

Sono essenziali per la diagnosi dei problemi di prestazioni Web, la risoluzione degli errori di rete e l'analisi delle transazioni API.

I registri HAR consentono di identificare le risorse a caricamento lento, le richieste non riuscite e di tenere traccia delle interazioni degli utenti con le applicazioni Web.

Limitazioni

• I file HAR possono essere di grandi dimensioni e difficili da analizzare manualmente.
• I dati sensibili possono essere registrati; garantire la pulizia dei dati prima della condivisione.
• Alcuni criteri di protezione possono bloccare l'acquisizione HAR completa.

Attenzione: Il file HAR include l'intero contenuto delle richieste e delle risposte in testo non crittografato (incluse password, ID sessione, cookie e così via). Pertanto, non è necessario condividere un file HAR acquisito in una sessione con un servizio disponibile al pubblico. Se la scheda Rete è stata aperta quando è stata immessa una password, il testo nel file HAR non è crittografato. Rimuovere queste credenziali prima di condividere il file HAR. Aprire il file HAR salvato in un editor di testo, trovare la password e sostituirla con un testo casuale come "". Non modificare la formattazione JSON del file durante l'esecuzione di questa modifica, in quanto non viene analizzata correttamente per la revisione.

Strumento purificatore HAR

Cronologia

Nel 2023, Okta ha avuto una violazione di sicurezza in cui i file HAR sono stati rubati dai loro sistemi di gestione dei casi di supporto. Gli aggressori hanno utilizzato il token di accesso e i cookie di questi file per ottenere l'accesso ai loro account cliente. In risposta, Okta ha implementato uno strumento di purificazione.

Stato attuale

Attualmente è in atto un'automazione in corso che tenta di rimuovere i materiali sensibili dalle tracce, ma lascia il resto intatto per preservare la capacità di risolvere i problemi e analizzare il problema.

Quando caricate un file HAR, lo strumento automaticamente:

1. Rileva che un file HAR è stato caricato
2. Rende puro il file HAR utilizzando https://har-sanitize.cisco.com
3. Carica il file igienizzato nella richiesta
4. Crittografa il file HAR originale utilizzando GPG
5. Carica il file HAR crittografato nella richiesta
6. Elimina il file HAR originale dalla richiesta
7. Aggiunge una nota che illustra le operazioni eseguite e un collegamento allo strumento.

Nota: Se non è possibile risolvere il problema utilizzando la versione eliminata del file HAR, è possibile archiviare un'eccezione come spiegato nelle sezioni successive e ottenere una copia del file HAR originale.

Come estrarre il registro HAR

Generare un file HAR nel browser

Per ulteriori informazioni, fare riferimento a: Generare un file HAR nel browser.

Estrai dal documento:

• Cromatura:
  Aprire Strumenti di sviluppo (F12) > Scheda Rete > Mantieni registro > Avvia registrazione > Riproduci problema > Esporta file HAR.
• Firefox
  Aprire Strumenti di sviluppo (F12) > Scheda Rete > Icona Motore > Controlla "Registri persistenti" > Avvia registrazione > Salva HAR.

Informazioni utili prima dell'analisi dei log HAR

Metodi HTTP

I metodi HTTP, noti anche come verbi HTTP, definiscono il tipo di operazione che un client desidera eseguire su una determinata risorsa, ad esempio dati o una pagina Web.

Ogni metodo ha uno scopo e una semantica specifici.

I metodi HTTP più comuni sono: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and TRACE.

* PATCH è generalmente idempotente, ma dipende dall'implementazione.

Spiegazione delle colonne

• Sicuro: indica se il metodo HTTP è considerato sicuro, ovvero non modifica le risorse o lo stato del server. I metodi sicuri sono destinati solo al recupero e non alla modifica. Vengono in genere utilizzati per operazioni di sola lettura.
• Idempotent: specifica se la ripetizione della stessa richiesta HTTP più volte ha lo stesso effetto della ripetizione di una sola volta. Un metodo idempotente indica che, indipendentemente dal numero di ripetizioni della richiesta, il risultato rimane invariato (dopo la prima richiesta riuscita)
• Uso tipico: descrive lo scopo o lo scenario comune per il quale viene utilizzato il metodo HTTP. In questo modo viene fornito il contesto per quando e perché è consigliabile utilizzare ogni metodo nello sviluppo Web o nella progettazione di API.
• Corpo richiesta: indica se la richiesta HTTP include in genere un corpo (dati inviati al server). Il corpo della richiesta viene spesso utilizzato per inviare dati, ad esempio JSON, XML o dati di modulo, al server, ad esempio durante la creazione o l'aggiornamento di risorse. 
• Corpo risposta: specifica se la risposta HTTP contiene in genere un corpo, ovvero i dati restituiti dal server. Il corpo della risposta è costituito dai dati restituiti dal server al client, ad esempio la risorsa richiesta, i messaggi di stato o la conferma di un'azione.

Anatomia di un registro HAR

Nota: Tutte le immagini di esempio in questa sezione sono state acquisite durante il tentativo di caricare i percorsi in Control HUB per un'organizzazione

Intestazioni

Acquisisce i metadati scambiati tra il client (browser) e il server durante le richieste e le risposte HTTP.

Le intestazioni forniscono il contesto dei dati inviati o ricevuti, ad esempio il tipo di contenuto, le informazioni di autenticazione, i criteri di memorizzazione nella cache e altro ancora.

Le intestazioni sono incluse nelle seguenti sezioni di un registro HAR:

1. Intestazioni richieste: Questi vengono inviati dal browser (client) al server come parte della richiesta HTTP.
2. Intestazioni risposta: Questi vengono restituiti dal server al browser in risposta alla richiesta.

Le intestazioni vengono archiviate come matrici di coppie chiave-valore, dove:

• Chiave: Nome dell'intestazione.
• Valore: Valore associato all'intestazione.

Intestazioni richieste comuni

1. Host: Specifica il nome di dominio del server (ad esempio as example.com) e il numero di porta.

• Esempio: Host: www.example.com

2. Agente utente: Identifica il browser o il client che effettua la richiesta, insieme alla versione e al sistema operativo.

• Esempio: Agente utente: Mozilla/5.0 \(Windows NT 10.0; Win64 x64

3. Accettare: Indica i tipi di contenuto che il client può gestire (ad esempio HTML, JSON, immagini).

• Esempio: Accetta: testo/html,applicazione/xhtml+xml

4. Accetta-Codifica: Specifica i tipi di codifica (ad esempio gzip, deflate) che il client può decodificare.

• Esempio: Accetta-Codifica: gzip, deflazionare

5. Autorizzazione: Contiene le credenziali per l'autenticazione, ad esempio token o credenziali di autenticazione di base.

• Esempio: Authorization: Bearer <token>

6. Cookie: Include i cookie inviati dal client al server.

• Esempio: Cookie: sessionId=12345; userPref=modalitàscura

7. Tipo di contenuto: Indica il tipo di dati inviati nel corpo della richiesta (per le richieste POST/PUT).

• Esempio: Content-Type: application/json

8. Referente: Identifica l'URL della pagina che fa riferimento al client alla risorsa corrente.

• Esempio: Referer: https://www.example.com/

Intestazioni risposte comuni

1.Tipo di contenuto: Specifica il tipo MIME della risorsa, ad esempio text/html, application/json.

• Esempio: Content-Type: application/json

2. Contenuto-Lunghezza: Indica le dimensioni del corpo della risposta in byte.

• Esempio: Content-Length: 1234

3. Controllo della cache: Specifica i criteri di memorizzazione nella cache per la risorsa, ad esempio se è inseribile nella cache e per quanto tempo.

• Esempio: Cache-Control: nessuna cache, nessun archivio, deve essere riconvalidato

4. Server: Identifica il software/la versione del server.

• Esempio: Server: Apache/2.4.29

5. Set-Cookie: Contiene i cookie che il server desidera vengano archiviati dal client.

• Esempio: Set-Cookie: sessionId=67890; Percorso=/; Protetto

6. Data: Data e ora in cui il server ha generato la risposta.

• Esempio: Data: Mar, 10 ott 2023 12:00:00 GMT

7. Luogo: Utilizzato nei reindirizzamenti, indica l'URL a cui deve passare il client.

• Esempio: Posizione: https://www.example.com/new-page

8. ETag: Identificatore univoco della risorsa, spesso utilizzato per la memorizzazione nella cache e il controllo delle versioni.

• Esempio: ETag: 12345abcd

9. Codifica del contenuto: Indica la modalità di codifica del corpo della risposta (ad esempio gzip, deflate).

• Esempio: Content-Encoding: gzip

10. Access-Control-Allow-Origin: Specifica le origini autorizzate ad accedere alle risorse (utilizzate in CORS).

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

Nota: L'elemento più importante per Webex Calling è l'intestazione Trackingid, in quanto è l'ID che è possibile cercare nello strumento LMA.

Payload

Dati inviati o ricevuti nel corpo di una richiesta o risposta HTTP.

In genere è associato alle richieste POST, PUT o PATCH, in cui il client invia dati al server, ad esempio l'invio di moduli, il caricamento di file o i dati JSON per le API.

Il payload può inoltre essere presente nelle risposte HTTP, che contengono i dati restituiti dal server, ad esempio HTML, JSON o contenuto binario, ad esempio immagini e file.

Dove viene visualizzato il payload nei log HAR

Il payload si trova in genere in due sezioni principali del log HAR:

1. Payload richiesta: Dati inviati dal client (browser) al server nel corpo di una richiesta HTTP.
2. Payload risposta: Dati restituiti dal server al client nel corpo di una risposta HTTP.

Anteprima

Fa parte dell'oggetto response.content e fornisce una rappresentazione dei dati restituiti dal server in un formato strutturato e leggibile, se disponibile.

L'anteprima viene in genere utilizzata per visualizzare dati analizzati o strutturati dal corpo della risposta in modo semplice, ad esempio JSON, XML o altri formati.

Questa sezione è particolarmente utile per eseguire il debug delle API, esaminare i dati restituiti o comprendere la struttura della risposta del server.

Risposta

La sezione Risposta fornisce informazioni dettagliate sulla risposta HTTP inviata dal server al client (browser) per una richiesta specifica. Questa sezione contiene metadati, intestazioni, dettagli del contenuto e altri dati critici che consentono di comprendere il comportamento del server durante il ciclo richiesta-risposta. Fornisce uno snapshot dettagliato della risposta del server a una richiesta HTTP.

Iniziatore

L'iniziatore fornisce informazioni dettagliate su ciò che ha attivato una richiesta HTTP specifica durante il caricamento di una pagina Web. Identifica l'origine o la causa di una richiesta di rete, aiutando gli sviluppatori a comprendere la catena di eventi che ha portato alla richiesta. L'iniziatore consente inoltre di tracciare l'origine di una richiesta e può puntare alla riga esatta di codice o risorsa responsabile della richiesta.

Intervallo

La tempistica fornisce un'analisi dettagliata delle varie fasi dell'elaborazione di una richiesta e di una risposta HTTP. Consente agli sviluppatori di comprendere il tempo necessario per ogni fase del ciclo richiesta-risposta, dall'avvio della connessione alla ricezione della risposta finale. La tempistica tiene traccia inoltre della sequenza e della durata degli eventi che si verificano quando un browser effettua una richiesta a un server e riceve una risposta. Include inoltre metriche dettagliate per la risoluzione DNS, la definizione della connessione, l'invio della richiesta, l'attesa della risposta del server e il download dei dati della risposta.

Risoluzione dei problemi

Strumento interno per la visualizzazione dei registri HAR

Passare a EasyLmaSearch > Import HAR/Saz file (Ricerca semplice > Importa file HAR/Saz).

Fasi generali della risoluzione dei problemi

1. Aprire il file HAR in un .
2. Identificare le richieste non riuscite (ad esempio errori HTTP 4xx/5xx).

3. Controllare i tempi di risposta e gli elementi a caricamento lento.

4. Analizzare le intestazioni di richiesta/risposta per l'autenticazione e i problemi CORS.

5. Cercare gli ID di rilevamento nelle richieste di rete e .
6. Se possibile, eseguire il controllo incrociato degli errori con le risposte.

Esempio di risoluzione dei problemi dai ticket

Elementi a caricamento lento

Esempio:

• Il caricamento dei numeri per una posizione da parte dell'hub di controllo richiede molto tempo

Risoluzione dei problemi:

• Richiedi un video del problema (tentativo di caricamento della pagina dei numeri per un'ubicazione)
• Richiedi un registro HAR durante il tentativo di caricamento dei numeri per un percorso

1. Aprire il file HAR in un visualizzatore HAR o in Strumenti di sviluppo del browser.
   
2. Identifica la richiesta nella cascata visualizzazione
   
3. Fare clic nella richiesta che richiede molto tempo per il caricamento.
4. Esaminare la scheda Timing (Tempistica) del registro:

5. Controllare i tempi di risposta e gli elementi a caricamento lento.

6. Raccogliere l'ID di traccia per l'intestazione.

7. Aprire EasyLMA e cercare con il trackingid.

Spiegazione delle fasi di analisi stratificata dei tempi

Di seguito sono riportate ulteriori informazioni su ciascuna delle fasi che è possibile visualizzare nella scheda Intervallo:

• In coda. Il browser accoda le richieste prima dell'avvio della connessione e quando:
  • Ci sono richieste con priorità più alta. La priorità della richiesta è determinata da fattori quali il tipo di una risorsa e la sua posizione all'interno del documento. Per ulteriori informazioni, consultare la sezione sulla priorità delle risorse della guida fetchpriority.
  • Esistono già sei connessioni TCP aperte per questa origine, che rappresenta il limite. Si applica solo a HTTP/1.0 e HTTP/1.1.
  • Il browser sta allocando brevemente spazio nella cache del disco.
• Bloccato. La richiesta potrebbe essere bloccata dopo l'avvio della connessione per uno dei motivi descritti in Accodamento.
• Ricerca DNS. Il browser sta risolvendo l'indirizzo IP della richiesta.
• Connessione iniziale. Il browser sta stabilendo una connessione, inclusi handshake TCP o tentativi e la negoziazione di un SSL.
• Negoziazione proxy. Il browser sta negoziando la richiesta con un server proxy.
• Richiesta inviata. Invio della richiesta in corso.
• Preparazione di ServiceWorker. Il browser sta avviando il Service Worker.
• Richiesta a ServiceWorker. Invio della richiesta al Service Worker in corso.
• In attesa (TTFB). Il browser è in attesa del primo byte di una risposta. TTFB è l'acronimo di Time To First Byte. Questo intervallo di tempo include 1 round trip di latenza e il tempo impiegato dal server per preparare la risposta.
• Download del contenuto. Il browser riceve la risposta direttamente dalla rete o da un service worker. Questo valore indica la quantità totale di tempo impiegata per la lettura del corpo della risposta. Valori maggiori del previsto potrebbero indicare una rete lenta o che il browser è occupato a eseguire altre operazioni che ritardano la lettura della risposta.

Risorsa non disponibile

Esempio: 

"Dopo aver abilitato SNR per l'utente sull'hub di controllo dell'amministratore, non è possibile impostare il numero SNR quando si accede al portale user.webex.com.
Puoi controllare la mia organizzazione e il mio utente per capire perché non riesco a vederlo nell'hub utente?"

Risoluzione dei problemi:

1. Confermare ciò che l'utente sta vedendo richiedendo uno screenshot di un utente attivo rispetto a un utente non attivo.

2. Richiedere un registro HAR durante il caricamento delle opzioni per l'utente.

Passaggi successivi:

1. Aprire il file HAR in un visualizzatore HAR o in Strumenti di sviluppo del browser. 
   
2. Identifica richieste:

Il servizio effettua una richiesta (GET) per conoscere i servizi dell'utente

Chiamata a richiesta di modello di accesso alle funzionalità dell'utente finale (GET) per il modello dei servizi visualizzati all'utente:

1. Analizza intestazioni richiesta/risposta.
   
   La voce "Nessun accesso" indica che il modello nasconde tali opzioni per l'utente.
2. È necessario rivedere il modello per l'ORG e attivare la portata Numero singolo affinché l'utente possa vederlo nell'hub utente.

Esempio:

Impossibile abilitare una funzionalità

Esempio con registrazione delle chiamate:

Quando si tenta di attivare la registrazione delle chiamate per un utente, viene visualizzato un messaggio di errore: "Modifica registrazione chiamate non riuscita".

Per risolvere i problemi:

1. Confermare l'errore richiedendo il testo completo del messaggio di errore.

2. Chiedi uno screenshot dell'errore.

3. Richiedere un registro HAR durante il tentativo di abilitare la "Registrazione delle chiamate" nell'utente interessato.

4. Aprire il file HAR in un visualizzatore HAR o in Strumenti di sviluppo browser.

5. Identificare le richieste non riuscite (ad esempio errori HTTP 4xx/5xx).

6. Cercare gli ID di rilevamento in EasyLMA.


7. Con l'eccezione cpapi, è possibile aprire un BEMS:

8. Aprire un BEMS con le informazioni raccolte:

• Schermate
• Messaggio di errore Complete
• ID rilevamento
• Eccezione cpapi
  
  

9. Chiedere nello spazio Dubber o al team BU di rivedere con il team Dubber l'errore:
"Riepilogo risposta di errore: 400: Prodotto non valido: Creazione del punto di postsonorizzazione non riuscita in Dubber. Stato HTTP: 502"

Messaggistica FAX

Di seguito è riportato il diagramma che illustra il flusso di provisioning durante lo spostamento tra i microservizi:

Quando si risolvono i problemi di provisioning dei messaggi fax all'interno di Control Hub, è essenziale raccogliere una traccia HAR per ottenere informazioni dettagliate sulla natura del problema e comprendere le cause degli errori di provisioning. 

Quando si abilita la funzionalità di messaggistica fax, la traccia HAR acquisisce e visualizza la richiesta pertinente da CH a CPAPI. La richiesta acquisita segue un formato specifico.

Dal CH → CPAPI:

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

Post Data {
"abilitato": vero,
"notifiche": {
"abilitato": vero,
"destinazione": "lazoclaudiafi+faxmessaging@gmail.com"
},
"sendAllCall": {
"abilitato": falso
},
"sendBusyCalling": {
"abilitato": vero,
"saluto": "PREDEFINITO"
},
"sendUnreplyCalles": {
"abilitato": vero,
"saluto": "PREDEFINITO",
"maxRings": 3
},
"transferToNumber": {
"abilitato": falso
},
"emailCopyOfMessage": {
"abilitato": vero,
"emailId": "lazoclaudiafi+faxmessaging@gmail.com"
},
"messaggio fax": {
"abilitato": falso,
"numero di telefono": "+1209193323",
"estensione": nullo
},
"archiviazione messaggio": {
"mwiEnabled" vero,
"tipo di storage": "INTERNO",
"postaEsterna": "lazoclaudiafi+faxmessaging@gmail.com"
}

Per tenere traccia in modo efficace di queste informazioni in EasyLMA, fare riferimento alle linee guida dettagliate fornite di seguito: 

Categoria: TrackingID
Sottocategoria: Globale
Webex Tracking ID: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Informazioni sulla segnalazione dei problemi

• File registro HAR
• Schermate di errori
• Passi per la riproduzione del problema
• Timestamp dell'incidente
• Log LMA

Rispondere a queste domande prima di aprire l'escalation BEMS, in quanto consente di risolvere i problemi in modo più efficace:

• Che errore vedi?
• Quali ID di rilevamento vedi?
• Hai esaminato l'ID di rilevamento in LMA?
• Cosa vedi in LMA?
• Questo BEMS è davvero necessario?