La stringa del cookie Discourse sopra riportata è lunga 1.962 caratteri!
A titolo di confronto, l’header cookie inviato al mio sito Mediawiki è lungo 122 caratteri, inclusi nome utente, ID utente e ID sessione.
L’ID sessione di Mediawiki è lungo 32 caratteri, ma Discourse sembra avere due ID sessione: rack.session è lungo 813 caratteri e _forum_session è lungo 1.075 caratteri. Potete aiutarmi a capire perché un semplice uid debba essere così lungo? Posso configurare Discourse per utilizzare un uid di sessione più breve? Ha senso una richiesta del genere?
Cosa viene memorizzato in quella stringa? È possibile ridurne le dimensioni?
Nello specifico, a quale componente del software Discourse serve rack.session? E a cosa serve _forum_session?
Certo, potrei semplicemente aumentare i limiti di configurazione di nginx, ma preferirei mantenerli ragionevolmente bassi a meno che non ci sia una forte necessità di aumentarli.
Supporto l’audit dei nostri cookie di sessione e, forse, il passaggio all’uso predefinito della nostra sessione basata su Redis, che scade automaticamente ed è comunque migliore. @david, hai qualche opinione al riguardo?
Dipende: i plugin che fanno un uso intensivo delle sessioni possono risentirne. È anche una questione di igiene: è meglio mantenere tutte queste informazioni riservate sul server invece che crittografate sul client.
Oh no, questa ottimizzazione è stata fatta intenzionalmente per motivi di sicurezza; non si tratta di un proxy “mal configurato”. Ridurre i seguenti direttive di nginx è una pratica comune per il loro hardening (per affrontare problemi di disponibilità, limitazione della frequenza, attacchi DOS, ecc.):
Le impostazioni che utilizziamo nella nostra configurazione di nginx funzionano perfettamente su tutti i nostri siti esistenti. Il problema qui sembra essere che Discourse memorizza dati client non necessari nel cookie, mentre a mio avviso l’unico dato che dovrebbe essere memorizzato nel cookie sono pochi identificatori univoci che il server può utilizzare per accedere a tali dati lato server.
Grazie, Sam. Con “passare all’uso predefinito di Redis” intendi suggerire che attualmente è possibile spostare i dati memorizzati nel cookie di sessione su Redis tramite una modifica alla configurazione? Oppure spostare questi dati dal cookie di sessione al server richiederebbe necessariamente una modifica al codice?
Perché 10k di intestazioni rappresentano un problema? Sono compresse; se 10k di intestazioni sono un problema, perché è consentito un payload HTML di 10k?
Nota: Ho anche dovuto sovrascrivere la direttiva large_client_header_buffers nella mia configurazione nginx hardened per far funzionare Discourse.
Nello specifico, per tutte le altre configurazioni nginx dei miei siti utilizzo large_client_header_buffers 2 1k. Tuttavia, questo causa un errore 414 Request-URI Too Large da /admin/reports/bulk?XYZ, dove XYZ è in realtà lungo 1.019 caratteri!
Il problema è stato risolto impostando large_client_header_buffers 4 8k; nel blocco server{} della configurazione nginx di Discourse, che sovrascrive la direttiva globale e ripristina il valore predefinito per Discourse.
Per migliorare l’interoperabilità delle installazioni di Discourse attraverso server web hardened popolari, firewall di rete e firewall per applicazioni web, esorto gli sviluppatori di Discourse a valutare l’uso del metodo POST per query string così lunghe.
Per qualcuno che non è un ingegnere backend, qual è la soluzione?
Stiamo ricevendo molte segnalazioni di questo errore nell’ultimo mese sul forum di Webflow. Consigliare a un visitatore di cancellare i cookie/la cache o di utilizzare la modalità di navigazione in incognito ha funzionato, ma non è l’ideale.
Qualsiasi consiglio per risolvere questo problema per la nostra istanza di Discourse sarebbe molto apprezzato.
Puoi fornire un link a un esempio? Il problema nell’OP riguarda l’auto-hosting di Discourse, quindi non capisco come possa influire su un’istanza ospitata come quella che hai linkato.