Preservare le sessioni utente durante la migrazione tra host

Supporto Installazione
1

Ciao!

Sto per migrare alcune istanze di Discourse su un nuovo hosting. Il piano prevede di impostare il vecchio sito in sola lettura, eseguire un backup, spostarlo sul nuovo hosting e ripristinarlo aggiornando al contempo le impostazioni DNS (con un TTL breve). Questo processo è tratto da guide presenti qui e altrove.

Ho già effettuato alcune prove, utilizzando una modifica al file /etc/hosts per simulare l’aggiornamento DNS (con anche DNS over HTTPS disabilitato nel browser). Finora tutto bene.

Tuttavia, nonostante abbia fatto attenzione a chiudere il browser sul sito ‘sorgente’ e ad aprirlo solo dopo il completamento della migrazione sul sito ‘destinazione’, il browser dimentica che ero loggato.

Ovviamente non voglio che tutti i membri del sito vengano disconnessi durante la migrazione. Dove dovrei guardare o cosa mi sto perdendo?

L’utente che sto testando ha privilegi di amministratore e utilizza l’autenticazione a due fattori (2FA), e i container di Discourse sono protetti da Nginx che termina l’SSL; questo potrebbe fare la differenza nel problema.

Grazie in anticipo per qualsiasi indicazione!

2

Anche io ho avuto questo problema e sono molto interessato a risolverlo.

Qualsiasi suggerimento è apprezzato.

3

Penso che proverò a creare alcuni account di test senza 2FA, nel caso abbia a che fare con il problema. Pochi membri del sito usano il 2FA, quindi potrebbe essere accettabile se sono solo quelle sessioni a andare perse.

Inoltre, controllerò che i server di origine e di destinazione siano sincronizzati con NTP, anche se ora non dovrebbero essere distanti tra loro di più di qualche secondo, penso.

Oltre a questo, immagino che ci sia sempre il codice sorgente da analizzare per capire cosa entra nel token di autenticazione e potrebbe causare il problema… :grimacing:

4

Il meglio da fare è informare i tuoi utenti del cambiamento, spiegando che verranno disconnessi e dovranno accedere nuovamente.

Ogni server ha una firma unica con SSL attivo.

Far accedere nuovamente l’utente sarà meno problematico che cercare di modificare le impostazioni del server.

Basta scusarsi per l’inconveniente causato, ma sottolineare che è per il meglio.

5

È davvero così?

Come vengono influenzati i cookie di sessione dalle “firme” SSL (specialmente nel mio caso, in cui il nuovo e il vecchio host utilizzano gli stessi file di certificato SSL, sullo stesso nome di dominio)?

6

Anche se non ho problemi a scusarmi con i membri (:slightly_smiling_face:), vorrei davvero evitare quella situazione, poiché vedo alcuni effetti collaterali negativi:

  1. I membri non accedono più e sono meno propensi a partecipare al forum in futuro.
  2. I membri dimenticano la password e hanno bisogno di aiuto per recuperarla.
  3. I membri dimenticano le password e creano nuovi account, lasciando molti “account zombie” sul forum e identità duplicate perse o confuse, senza note utente o cronologia dei post, ecc.

La parte SSL funziona perfettamente davanti a Discourse (anche con l’hack del file hosts), il che, se ci pensate, deve essere così, altrimenti i bilanciatori di carico avrebbero problemi. Per quanto ne so, Discourse non è nemmeno a conoscenza della SSL, poiché in questa configurazione viene terminata a livello di Nginx.

Suppongo che la domanda diversa sia: “È possibile migrare un server Discourse su un nuovo IP senza disconnettere tutti?”. Avevo assunto che fosse possibile, ma forse quell’assunzione era errata… :frowning:

7

So che di sicuro ho avuto sessioni del forum sopravvissute a un backup e ripristino. Non sono davvero sicuro di cosa stia succedendo qui :frowning:

8

I cookie di sessione sono crittografati utilizzando una chiave segreta generata casualmente che, per impostazione predefinita, è memorizzata in Redis. I dati di Redis non sono inclusi nei backup, quindi quando ripristini il sito su un nuovo server viene generata una nuova chiave segreta.

Puoi impostare manualmente la chiave segreta utilizzando una variabile d’ambiente DISCOURSE_SECRET_KEY_BASE nel tuo file app.yml. Quindi potresti provare qualcosa del genere per preservare le sessioni:

  1. Sul tuo server esistente, apri la console e trova la chiave segreta da Redis

    pry(main)> GlobalSetting.safe_secret_key_base
=> "5fb9dc98be368599e0a..."

  2. Aggiungi DISCOURSE_SECRET_KEY_BASE alla sezione env: del tuo file app.yml sul vecchio server, utilizzando il valore trovato al punto (1), e ricostruisci l’app. In teoria, se tutto è andato bene, Discourse dovrebbe ora utilizzare il valore presente nell’app.yml e le sessioni degli utenti rimarranno attive. Puoi verificare che la variabile d’ambiente venga utilizzata eseguendo

    GlobalSetting.secret_key_base

  3. Assicurati che l’app.yml sul nuovo server contenga lo stesso SECRET_KEY_BASE. Quando ripristini il backup, le sessioni degli utenti dovrebbero rimanere attive.

Non ho testato questo flusso, quindi se prevedi di utilizzarlo per un forum di produzione assicurati di provarlo prima!

Nota a margine: non dovresti assolutamente condividere la chiave segreta tra più istanze di Discourse. La possessione della chiave segreta permetterebbe a qualcuno di decrittografare e modificare il proprio cookie di sessione su un sito, con conseguenze di sicurezza molto gravi.

9

Ottimo - proverò questa soluzione su un’istanza sandbox. Vedrò se riesco a fare un resoconto sul suo funzionamento :slight_smile:

Capito. Sto riflettendo sulla possibilità di presentare una richiesta di funzionalità per aggiungere un’opzione per esportare questa chiave nei backup. Per me, perdere tutte le sessioni su un sito sarebbe un evento “molto negativo”, considerando che ci sono diverse migliaia di account registrati. La prova della migrazione ha messo in luce questo problema, ma immagino che se la macchina o l’istanza Docker andassero perduti per qualche motivo, anche la chiave verrebbe persa, con la stessa conseguenza di perdere tutte le sessioni.

Sarebbe utile aggiungere una nota su questa “funzionalità” nell’argomento relativo alla migrazione: Move your Discourse Instance to a Different Server

10

È un delicato equilibrio tra sicurezza e comodità.

Al momento, se qualcuno riesce a rubare un backup di Discourse, ha accesso a tutti i dati del forum. Tuttavia, non può accedere al forum attivo. Le password sono hashate, le chiavi API sono hashate e i cookie di sessione sono cifrati.

Se includessimo il segreto all’interno del backup, chiunque fosse in possesso di un backup potrebbe accedere al forum attivo e compiere azioni come phishing, frodi, ecc.

Ottimo! Sono assolutamente disponibile a creare un argomento qui su Meta che spieghi come migrare da una chiave segreta Redis a una chiave segreta app.yml. Potrebbe essere collegato dall’argomento “spostamento su un server diverso”.

11

A mio modesto parere, anche la sicurezza dei backup predefiniti dovrebbe essere migliorata. Anche se le password e le sessioni possono essere crittografate e protette, nei messaggi privati e in altri contenuti potrebbero esserci molti dati che dovrebbero rimanere confidenziali. Si noti in particolare che nel nostro forum della comunità incoraggiamo le persone a utilizzare i messaggi privati per scambiarsi i dati di contatto e organizzare vendite o ritiri, piuttosto che inserire numeri di telefono e indirizzi in luoghi pubblici.

L’approccio che sto adottando per i backup è accedere all’istanza, generare un backup e poi crittografarlo immediatamente con una chiave pubblica utilizzando GPG. Questo rende il backup inutile per chiunque non possieda la corrispondente chiave privata, che conservo al di fuori del server e protetta da una passphrase.

Detto questo, se la chiave segreta per le sessioni non cambia, è sufficiente un backup una sola volta, quindi è necessaria solo una procedura semplice per questo, e speriamo sia proprio ciò che hai descritto sopra.

Proverò a farlo e vediamo se riesco a creare quel topic per te :slight_smile:

12

Molto utile @david, grazie!

13

Discourse non offre i messaggi privati; la funzionalità si chiama Messaggi Personali. La distinzione è molto importante: non vi è alcuna implicazione di privacy.

Gli amministratori possono già leggere ogni messaggio privato sul sito, a meno che non sia in uso la crittografia.

14

Buon punto. Ma questo non cambia il fatto che i membri possano utilizzare i messaggi privati per scambiarsi dati personali o informazioni che non desiderano rendere pubbliche. Proteggere questi dati, per quanto ragionevole, è quindi importante.

Sì, dobbiamo anche fidarci degli amministratori di ogni sito che utilizziamo, anche su siti come ProtonMail.

15

Un po’ fuori tema… ma potresti essere interessato a Discourse Encrypt (deprecated) per messaggi davvero ‘privati’. Backup trapelati o rubati di messaggi privati crittografati non sarebbero leggibili da un attaccante.

(sebbene, come hai detto, si dà ancora per scontato che gli amministratori siano fidati)

16

@david - per favore, puoi controllare il seguente post e spostarlo in howto se va bene? (Non posso creare un argomento lì, e poi Akismet ha appena nascosto il post, quindi va anche sistemato quello :blush: )

18

@david - mille grazie per aver risolto il problema e per il consiglio, spero che aiuti anche gli altri - è sicuramente un sollievo per noi poter migrare e mantenere le sessioni :partying_face: