Questo continua a verificarsi casualmente a tutti gli utenti. Non è successo a me, ma una volta sono stato disconnesso quando è successo a qualcun altro. Non ho idea da dove iniziare a cercare.
Ho un thread aperto sul mio forum che ho reso pubblico per fornire maggiori informazioni. Questa volta 2 utenti sono stati effettuati l’accesso come lo stesso utente, uno un amministratore, l’altro no. L’utente in cui sono diventati non è nemmeno attivo.
@Falco Qualsiasi intuizione su dove guardare è apprezzata.
@Falco questo è un problema in corso da diversi anni. Per quanto ne so, si tratta di un problema con la sessione utente lato client e specificamente con lo userID. Questo problema viene solo aggirato, non risolto, se invece dell’accesso locale, ovvero autenticazione locale, viene utilizzata l’autenticazione di terze parti.
Puoi confermare che ciò è causato dalla tua autenticazione locale scadente?
Con tutto il rispetto, ci sono molte migliaia di installazioni di Discourse in giro per internet. Solo nel nostro hosting ne gestiamo migliaia, e ce ne sono molte anche self-hosted, e la tua istanza è l’unica a segnalare questo problema. Ciò significa che il tuo problema è molto probabilmente auto-inflitto.
Dato che stai eseguendo un reverse proxy personalizzato davanti a Discourse, inizierei a rimuoverlo e a passare alla nostra configurazione di installazione standard consigliata prima di segnalare il bug a monte qui.
Non sono sicuro di cosa renda la mia configurazione personalizzata rispetto a ciò che è integrato in Discourse, dato che entrambi sono nginx. Tuttavia, non è possibile per me rimuoverlo poiché Discourse non è l’unica cosa che ospito. Sono sicuro che è un mio problema, ma se può succedere a me, può succedere a chiunque. Non ho altri problemi con il software che sto ospitando. Non ti sto chiedendo di prenderti cura di me, ma non riesco a trovare nient’altro che possa essere sbagliato.
Se non ci sono altre intuizioni che tu possa darmi su dove cercare, forse conosci qualcuno che può farlo. Ho provato a controllare i log di entrambi i container così come i rispettivi host. Non sono sicuro di dove altro cercare per capire cosa è andato storto.
Capisco la mancanza di supporto. Non siamo clienti paganti e alcuni di noi non sono nemmeno molto gentili. Non ti incolpo se mi punti il dito, perché sono d’accordo, è qualcosa che sto facendo diversamente a causare questo mal di testa. Se tuttavia credi sinceramente che il reverse proxy sia ciò che causa questo problema, non rappresenterebbe forse un grosso problema di sicurezza?
Non so quali siano i dettagli interni di discourse, ma per me questo sembra qualcosa che dovrebbe interessare gli sviluppatori.
Sì, è decisamente un problema di sicurezza. Ma se si verifica solo in questa specifica istanza, è un problema di sicurezza sul tuo sito, e non su Discourse, giusto?
Sarei felice di aiutarti qui. Saresti disposto a spostare il sito su un server separato per un paio di settimane utilizzando la nostra installazione standard per escludere eventuali problemi di reverse proxy?
Se il mio reverse proxy è in grado di manipolare qualche token o altro nel modo giusto in modo che Discourse creda che un utente sia diventato qualcun altro… ha davvero importanza se il problema risiede nel reverse proxy? Non indicherebbe qualcosa di sfruttabile altrove?
Di nuovo, non sapendo cosa non so su come funziona l’autenticazione.
Ci siamo allontanati dall’hosting di terze parti a causa dell’aumento dei costi, ma potrebbe esserci un altro modo per affrontare la cosa. Indagherò sul reverse proxy. Attualmente uso questo container per facilitare l’amministrazione, tuttavia potrei provare qualcosa di diverso.
So che stai dicendo che succede solo a me, e non ho prove del contrario, ma significa davvero che non è possibile per nessun altro?
Farò qualche ricerca sulla configurazione nginx che Discourse fornisce per vedere se riesco a capire dove sto sbagliando. Apprezzo la tua intuizione.
Non pretendo di capire nulla qui e ora, ma quando ho iniziato a usare Discourse avevo Varnish davanti a Discourse e ho riscontrato molte cose strane, come contenuti errati.
Discourse fa la sua cache e praticamente qualsiasi tipo di caching da parte di un reverse proxy è una pessima idea che fa perdere molto tempo. Ma certo, le mie capacità molto limitate sono molto diverse da ciò che i Big Guys™ possono fare.
Mi ha chiesto di rimuovere completamente il proxy inverso. Si tratta semplicemente di rimuovere alcune cose dalla configurazione del proxy. Non sapevo che Discourse stesse effettuando il caching internamente, il che sarebbe entrato in conflitto con il caching esterno, quindi questo è un suggerimento utile.
[quote=“Jakke Lehtonen, post:33, topic:328698, username:Jagster”]
Quindi farai essenzialmente ciò che Falco ha già suggerito un paio di volte
[/quote]Il link che continua a spammare è ciò che stiamo già facendo:
questi passaggi funzioneranno su qualsiasi provider cloud compatibile con Docker o server locale.
Sta eseguendo il container standard. La documentazione menziona l’utilizzo di una macchina “compatibile con Docker”, che sta utilizzando. La documentazione menziona persino l’utilizzo di un server locale, che sta utilizzando.
Non c’è menzione dell’utilizzo di un proxy speciale approvato o della disabilitazione della cache.
C’è anche la documentazione per la configurazione dell’SSO, che sembra aver causato problemi simili a quelli che stiamo riscontrando in passato:
Ancora nessuna menzione della configurazione della cache o di soluzioni di reverse proxy “personalizzate”.
Come minimo, suggerirei di aggiornare la documentazione per evidenziare questi potenziali problemi, poiché sono così evidenti per gli esperti di Discourse.
Sarei molto preoccupato per quella configurazione della cache. Non capisco appieno la documentazione di nginx per proxy_ignore_headers, ma per impostazione predefinita nginx non memorizza nella cache le risposte che includono un’intestazione Set-Cookie. Sembra che quella configurazione stia cambiando quel comportamento in modo che le risposte che includono un’intestazione Set-Cookiepossano essere memorizzate nella cache. Se vengono memorizzate nella cache con l’intestazione Set-Cookie e poi servite a un utente diverso, ciò potrebbe causare il cambio di account utente di qualcuno.
In teoria, quella configurazione dovrebbe applicarsi solo ai file multimediali, ma far corrispondere la parte finale di un URL (inclusi i parametri di query?) sembra un modo piuttosto insicuro per farlo.
Ho interrotto il suo utilizzo. Dato che altri hanno sottolineato che sembra un’idea piuttosto pessima in generale, apprezzo la spiegazione. Non ho visto immediatamente nulla di sbagliato in quello che stava facendo, ma certamente non sono un esperto della materia.
