Come si tiene con sicurezza la registrazione del controllo periodico senza Internet?

Risposta breve: come si tiene la registrazione di controllo senza Internet?

Salvate il modulo di controllo in un database locale transazionale sul dispositivo; assegnate a ogni registrazione un identificativo di transazione univoco, mantenete visibile lo stato di invio e, alla ripresa della connessione, riconciliate con il server senza generare duplicati.

Nel lavoro offline “salvato” non è un unico stato. All'utente vanno mostrati distintamente gli stati salvato sul dispositivo, in attesa di invio, accettato dal server e richiede revisione Così, con connessione debole, il fatto che il modulo compaia sullo schermo non fa credere che sia giunto alla sede centrale.

Quali dati vanno caricati sul dispositivo prima di uscire per il campo?

Risposta breve: va caricato solo il pacchetto dati aggiornato e autorizzato, necessario al completamento dell'incarico assegnato.

• Ordine di lavoro e identificativo immutabile dell'attrezzatura
• Versione fissata del modulo di controllo dipendente dal tipo di attrezzatura
• Criteri di controllo necessari ed elenchi di selezione
• Ambito di incarico e riferimenti del dispositivo del personale assegnato
• Data e ora dell'ultima sincronizzazione e versione del pacchetto

La specifica W3C Service Workers illustra che è possibile realizzare applicazioni web offline con worker che intercettano le richieste e un archivio locale di richieste/risposte. L'equivalente nel flusso VizyonTech non è mettere in cache il solo guscio della pagina; è predisporre, in un pacchetto verificato prima del campo, i moduli e i dati di riferimento dell'incarico assegnato.

Se il pacchetto non è aggiornato, l’applicazione non deve aprire silenziosamente un vecchio modulo. Devono essere visibili l’ultima sincronizzazione, la versione del modulo e il limite di utilizzo offline. Se mancano dati anagrafici critici, il sistema deve bloccare la creazione della registrazione secondo il principio fail-closed. Il rapporto tra ordine di lavoro, attrezzatura e modulo è illustrato nella guida al piano di controlli periodici .

Come va salvato il modulo sul dispositivo?

Risposta breve: scrivete ogni modifica di campo non in un buffer temporaneo dello schermo, ma in una transazione breve e atomica di un database locale.

La bozza W3C IndexedDB 3.0 definisce, per le esigenze web offline, la conservazione locale di oggetti strutturati e transazioni che vengono scritte per intero oppure annullate in caso di errore. Nel modulo di campo ciò significa scrivere valore di misura, unità, descrizione, collegamento alla foto e data e ora della registrazione in una versione di bozza coerente.

Il pulsante di salvataggio deve mostrare l'esito positivo solo quando la transazione locale è completata. La chiusura dell'applicazione, l'esaurimento della batteria o il ritorno momentaneo della rete non devono portare un modulo incompleto allo stato “inviato”.

Come va eseguita la sincronizzazione quando torna la connessione?

Risposta breve: inviate la coda in ordine, riprovate ogni elemento con lo stesso identificativo di transazione e contrassegnate come completato solo dopo una risposta di accettazione esplicita del server.

1. Verificate non la semplice presenza della connessione, ma l'accesso effettivo al server applicativo.
2. Ricontrollate l'integrità locale della registrazione in coda e i suoi campi obbligatori.
3. Inviate la registrazione con i suoi allegati mediante identificativo di transazione immutabile e versione locale.
4. Eseguite sul server i controlli di autorizzazione, ordine di lavoro, versione del modulo e versione attuale della registrazione.
5. In caso di accettazione riuscita, scrivete sul dispositivo l'identificativo della registrazione lato server e l'orario di accettazione.
6. Distingue gli errori temporanei, da tentativo controllato, dagli errori di validazione permanenti, da revisione umana.

L'RFC 9110 spiega che una richiesta idempotente può essere ripetuta dopo un errore di connessione con lo stesso effetto previsto. Nella registrazione di un controllo periodico il nome del metodo non basta: il server non deve aggiungere come nuova relazione una seconda richiesta con la stessa chiave di transazione; deve restituire l'esito dell'accettazione precedente.

La Background Synchronization API può rinviare l'operazione al service worker al ritorno della connessione; tuttavia MDN la segnala come funzionalità priva di ampio supporto browser. Per questo la coda non deve dipendere solo dall'evento in background; deve funzionare in modo affidabile anche all'apertura dell'applicazione e all'azione “invia ora” dell'utente.

Cosa succede se la stessa registrazione viene modificata su due dispositivi?

Risposta breve: non usate l'approccio “vince l'ultimo che scrive” sui campi di misura e di conformità; fermate il conflitto di versione e mostrate entrambe le modifiche a un utente autorizzato.

Se la versione sul server è più avanzata della versione base ricevuta dal dispositivo all'avvio dell'incarico, una sovrascrittura automatica può causare perdita di dati. I campi non in conflitto possono essere uniti in modo controllato; se la stessa misura, lo stesso esito o la stessa descrizione critica sono cambiati da entrambe le parti, la registrazione deve essere portata richiede revisione in tale stato.

• Confrontate la versione del server con la versione base del dispositivo.
• Conservate nel registro delle operazioni i campi modificati e gli attori.
• Non sostituite silenziosamente una relazione pubblicata con una bozza offline.
• Registrate la risoluzione del conflitto come nuova revisione con relativa motivazione.
• Mostrate chiaramente all'utente su quale dispositivo è in attesa la registrazione.

Come vanno protetti i dati offline sul dispositivo?

Risposta breve: scaricate solo i dati necessari, proteggete i dati locali con l'archivio sicuro della piattaforma e applicate una pulizia controllata legata al ciclo di vita del dispositivo o della sessione.

OWASP MASVS-STORAGE-1 richiede la conservazione sicura dei dati sensibili indipendentemente dalla loro posizione sul dispositivo. MASWE-0006 raccomanda invece di non conservare localmente dati sensibili non necessari, di proteggere le chiavi nell'archivio sicuro della piattaforma e di usare una crittografia adeguata.

• Nel pacchetto offline includete solo l'incarico assegnato, non l'intero archivio clienti.
• Proteggete chiave di sessione, dati personali, foto e allegati di misura secondo la classe di dati.
• Non conservate la chiave di crittografia accanto al file dati o nel codice sorgente.
• Collaudate gli scenari di perdita del dispositivo, cambio utente e revoca dell'autorizzazione.
• Pulite in modo sicuro gli allegati locali inviati secondo la politica di conservazione.
• Non scrivete registrazioni sensibili in aree file condivise o in copie di sicurezza non controllate.

Il lavoro offline non elimina il controllo di autorizzazione. Anche se il dispositivo ha già ottenuto l'autorizzazione, durante la sincronizzazione il server deve riverificare utente, organismo, ordine di lavoro e versione del modulo.

Quali scenari vanno collaudati prima della messa in produzione?

Risposta breve: il test in modalità aereo non basta; occorre dimostrare che l'interruzione si verifica in ogni fase della registrazione e che il nuovo tentativo non genera duplicati.

1. L'applicazione si apre quando è offline per la prima volta, oppure segnala correttamente la preparazione mancante?
2. Se l'applicazione si chiude durante la registrazione di un campo, l'ultima transazione locale completata viene conservata?
3. Se la connessione si interrompe durante il caricamento di una foto, il legame tra modulo e allegato si spezza?
4. Se il server accetta la registrazione ma la risposta non raggiunge il dispositivo, il reinvio apre una seconda registrazione?
5. Quando la versione del modulo cambia nella sede centrale, come viene risolto il vecchio lavoro offline?
6. Quando lo stesso incarico è modificato su due dispositivi, il conflitto sui campi critici blocca l'operazione?
7. Quando un utente con autorizzazione revocata si riconnette, l'invio viene rifiutato e la registrazione conservata?
8. Quando la coda resta in attesa per giorni, l'utente riesce a capire quali registrazioni non sono ancora pervenute alla sede centrale?

Vizyon Periyodik nella valutazione, la funzione offline non va collaudata solo con la demo “il modulo si apre”; vanno testati congiuntamente commit locale, coda visibile, accettazione idempotente, gestione dei conflitti e sicurezza del dispositivo. Per le altre porte fail-closed nella scelta del software, consultate la guida alla scelta del software di controlli periodici .