Abbiamo riscontrato un grave problema di sicurezza con il sistema di inviti. Suppongo che sia facilmente riproducibile. Il nostro sito è ad inviti. Inoltre, abbiamo selezionato “devono approvare gli utenti” nelle impostazioni.
Uno dei nostri staff ha emesso un invito con un numero massimo di utilizzi superiore a 1, quindi non limitato a una specifica email (esempio sotto).
Quel link di invito è circolato e le persone hanno potuto registrarsi con esso. Tuttavia, ci aspettavamo che quando “devono approvare gli utenti” è selezionato nelle impostazioni, lo staff dovesse approvare chiunque utilizzasse quegli inviti “senza restrizioni di email”. Invece, sono stati tutti fatti entrare automaticamente, chiunque avesse quel link. Quindi il link può essere usato da chiunque e non possiamo controllare chi entra con esso. Dobbiamo essere in grado di effettuare un “controllo preliminare”, utilizzando la combinazione di email, nome e altri campi che abbiamo aggiunto, che sono campi obbligatori che chiediamo di approvare (dopo che abbiamo controllato).
Questo ha creato un grave problema poiché qualcuno di un’organizzazione straniera strettamente proibita ha ottenuto quel link e si è registrato. Ho dovuto eliminare quell’account subito. Questo è un grave problema per noi.
Trovo quindi che l’opzione “devono approvare gli utenti” sia pericolosamente fuorviante. Attualmente quell’opzione è inutile se siamo su un’istanza solo su invito.
C’è un modo per consentire allo staff di approvare qualcuno che utilizza il link di invito che non è stato limitato via email? Sembrerebbe un modo logico per abilitare “devono approvare gli utenti” quando il sito è solo su invito.
Posso riprodurre il problema: quando viene generato un invito in blocco, gli utenti che si registrano con quel link sono automaticamente immuni all’impostazione “gli utenti devono essere approvati”.
C’è interesse a risolvere questo problema? Se non affrontato, alla fine questo problema bloccherà il nostro progetto Discourse nella nostra organizzazione.
Hai visto qualcosa nella documentazione che ti ha portato a credere che gli inviti non legati a un’email aggiungessero il passaggio di approvazione @Wall-E?
La cosa fondamentale qui è che un membro dello staff ha emesso l’invito. Discourse lo tratta come un’approvazione implicita degli utenti che utilizzano l’invito.
Se un membro non dello staff ha generato l’invito, l’utente che lo riscatta verrebbe aggiunto alla coda per l’approvazione dello staff.
quindi se un account utente non staff viene utilizzato per creare un invito, le iscrizioni tramite quell’invito finirebbero nella coda di revisione? Se è così, è un comportamento assolutamente accettabile e @Wall-E potresti usare un account regolare fittizio per generare l’invito come soluzione temporanea.
Penso che dovrebbe esserci almeno un avviso per gli utenti dello staff, e sarebbe fantastico se potessero scegliere come verranno trattati i nuovi membri. Usare un secondo utente, “normale”, sarebbe una brutta soluzione temporanea.
Leggendo questo e gli argomenti precedenti, posso vedere che il funzionamento attuale è “by design” ma non riflette le nuove modifiche al sistema di inviti. È diventato molto più facile creare link di invito che possono essere utilizzati da persone sconosciute. I link di invito ora possono anche essere creati pericolosamente da staff che aggiungono invitati a gruppi che possono avere accesso a categorie sicure sul sito.
@Wall-E Sono curioso di capire come i tuoi link di invito cadono nelle mani di persone a cui non dovrebbe essere consentito l’accesso al tuo sito. Presumibilmente lo staff del tuo sito saprà stare attento a non creare link di invito che chiunque possa utilizzare e condividerli pubblicamente o in contesti in cui le persone sbagliate potranno utilizzarli. In una certa misura, il problema che stai affrontando è un problema di formazione dello staff. Sentiti libero di inviarmi un messaggio privato con la tua risposta se contiene dettagli sensibili.
Se ci sono link di invito esistenti attualmente che sono in qualche modo compromessi, puoi eliminarli e crearne di nuovi e condividerli con più attenzione in futuro. Come amministratore, puoi anche sempre controllare nella pagina degli inviti per l’utente per vedere chi ha riscattato i propri inviti. Se hai staff di cui non ti fidi, puoi abbassare i loro privilegi a TL4, che ha quasi privilegi di moderatore.
Vedo tre possibili corsi d’azione:
Non fare nulla. Il sistema di inviti funziona come previsto, lo staff deve solo fare attenzione con i propri link di invito. Se scegliamo questa strada, suggeriamo di modificare la descrizione dell’impostazione di amministrazione must approve users per chiarire che i link di invito creati dagli amministratori aggirano questa impostazione.
Lo staff deve approvare tutti i nuovi account utente prima che sia loro consentito accedere al sito. Nota: gli inviti creati dallo staff aggirano questa impostazione e non richiedono approvazione.
Fai (1) ma aggiungi anche un passaggio di avviso extra “sei sicuro” quando gli amministratori creano un link di invito che può essere utilizzato per ottenere immediatamente l’accesso al sito. Solo sui siti con approvazione richiesta.
Cambia il comportamento in modo che i link di invito creati dagli amministratori rispettino l’impostazione di approvazione richiesta proprio come gli inviti dei non amministratori.
Sono d’accordo con l’OP sul fatto che il comportamento attuale sia fuorviante e abbia il potenziale di causare problemi sui siti quando l’approvazione è richiesta. I siti con questa impostazione abilitata sono estremamente cauti e necessitano di questo livello extra di controllo paranoico su chi può ottenere l’accesso.
La mia raccomandazione sarebbe quindi quella di scegliere la porta numero tre: far funzionare tutti i link di invito allo stesso modo e rispettare l’impostazione must approve users.
Non penso che questo sia un bug, tuttavia. Funziona come previsto. Riclassificato come richiesta di funzionalità.
Sono anche fortemente a favore dell’opzione 3. Sto costruendo una community in cui le persone possono riflettere più profondamente sulle emozioni e penso che aggiungere quel livello extra di controllo sui link di invito anonimi (poiché non sono collegati a un indirizzo email o a un’identità) potrebbe farmi sentire più tranquillo che solo le persone che voglio che si uniscano lo faranno.
Suppongo di poter assicurarmi di utilizzare l’email di invito invece del link di invito anonimo, ma il link rende molto più facile la condivisione su Whatsapp o altre piattaforme di comunicazione.
Quindi sono anche a favore del far sì che i link di invito anonimi rispettino l’impostazione “approva utenti”.
Inoltre, penso che se accadesse il #3, il sistema di invito potrebbe funzionare quasi come un sistema di candidatura per forum solo su invito. Al momento, non sono sicuro di come farei in modo che le persone facciano domanda per diventare membri senza avere un Google Form separato o simile. Questo potrebbe semplificarlo in un certo senso, dove i campi utente personalizzati potrebbero essere il modulo di candidatura, che è ciò che penso @Wall-E stia cercando di fare.
L’argomento di cui sto parlando non è questo. Sto parlando del fatto che must_approve_users non ha alcun effetto in un’istanza solo su invito. Attivarlo dovrebbe avere un effetto diverso rispetto a disattivarlo. In caso contrario, dovrebbe essere documentato che questo comportamento non si applica alle istanze solo su invito. Se me lo sono perso nella documentazione, allora è effettivamente responsabilità del nostro staff. Ma se non lo è, allora quella funzionalità è fuorviante e dovrebbe essere corretta, o almeno documentata, poiché ha tratto in inganno tutto il nostro staff.
Assolutamente. Potrei essermi perso la documentazione, se fosse stata documentata, allora sarebbe mia responsabilità aver tratto in inganno il mio staff, e un avviso non guasterebbe, perché le persone/lo staff possono dimenticare.
Citerò le persone che hanno il potere di chiuderci a causa di questo aspetto, considerato un problema di sicurezza nella nostra organizzazione: “Se questo sistema può permettere l’ingresso a qualcuno di un’organizzazione non autorizzata, devi presumere che alla fine succederà, indipendentemente dalla tua diligenza”. Questo è esattamente ciò che è successo. Quella “funzionalità” (direi, una non-funzionalità poiché il parametro “must_approve_user” non ha alcun effetto nel caso di invito, ndt) è stata abilitata, abbiamo emesso l’invito illimitato alle persone esatte che volevamo invitare, e ovviamente, una di queste persone ha condiviso quel link di invito illimitato con un’altra organizzazione.
Con questo rispondo anche a @tobiaseigen
Abbiamo riunioni, conferenze, con a volte centinaia di persone da organizzazioni autorizzate che possono unirsi al nostro forum. Ma alcune di queste persone provengono a volte da altre organizzazioni non autorizzate a unirsi al nostro forum (a causa di politiche generali fuori dal nostro controllo).
Quel link di invito è sfuggito al controllo, anche con la diligenza dello staff, poiché non possiamo controllare cosa faranno le persone “implicitamente autorizzate” con quel link; per definizione, quel link è “illimitato”, quindi possono inoltrarlo a chiunque vogliano. Non posso incolpare il mio staff per questo, poiché se dici che è “per progettazione” c’è un’approvazione implicita, significa che questo link di invito illimitato può finire ovunque, quindi alla fine succederà. Questo è esattamente ciò di cui parlava il capo del nostro dipartimento IT, a buona ragione. Lo sapevamo, e quindi abbiamo abilitato il parametro “must_approve_users” per agire come quel livello di sicurezza che pensavamo fosse.
Vedo che c’è una domanda se si tratti di una funzionalità o di un bug. Non sono un programmatore professionista, spetta a voi deciderlo (sono un astrofisico). Sto semplicemente segnalando un grave “problema” che ci ha causato, sperando che possa essere risolto in modo da poter continuare a utilizzare questa meravigliosa piattaforma.
Sono pienamente a favore dell’opzione 3, così come il nostro centro di ricerca e il mio staff del forum. Fino a nuovo avviso, lo staff è istruito a non utilizzare l’invito illimitato. Il che aggiunge un onere extra poiché ora devono aggiungere tutti gli indirizzi email individuali delle persone che vogliono invitare (e a una conferenza, si tratta di più di centinaia di partecipanti…). Farlo ad ogni riunione, evento, ecc… aggiungerà un’elevata viscosità alla nostra crescita, e posso prevedere che alcuni membri dello staff se ne andranno a causa del carico di lavoro aggiuntivo (la maggior parte di loro sono volontari, e tutti oberati di lavoro con i loro altri compiti).
È sicuro presumere che se l’opzione 3 dovesse essere approvata, ci sarà un’opzione per mantenere il comportamento esistente?
Il sito di formazione che abbiamo messo insieme sarebbe stato molto più difficile da realizzare senza la possibilità di bypassare le approvazioni per i gruppi invitati in massa.
Non dimenticare che anche gli inviti in blocco sono un’opzione qui, se il tuo evento genera un csv di partecipanti puoi usarlo per invitare tutti direttamente.
In caso contrario, puoi anche condividere un url a un modulo web per popolare un CSV e convalidare gli utenti lì prima di inviare l’invito in blocco.
Purtroppo i nostri eventi tipici non ci danno accesso a ciò. Tali elenchi di contatti sono trattati come PII (Personally Identifiable Information) dall’organizzazione ospitante che ospita la conferenza/riunione. Anche se avessimo accesso, semplicemente non abbiamo la larghezza di banda per utilizzare tale funzionalità. Dovremmo metterci in contatto con un POC, che è sempre oberato di lavoro (anche se ci è permesso avere accesso alle informazioni), quindi ancora una volta, alta viscosità, quando otteniamo i link di invito, l’evento è finito, lo slancio è perso (dal nostro staff e dai nostri potenziali invitati).
Preso atto. Potrebbe essere una soluzione alternativa. Ma questo comporterebbe un carico di lavoro aggiuntivo per il nostro personale, che non ha molta larghezza di banda per elaborare questo passaggio extra. Quindi, non è l’ideale.
Mi dispiace che questo ti abbia causato problemi e alla tua community!
In futuro, ora sai come funziona, così potrai assicurarti che tu e gli altri amministratori e moderatori utilizzerete il sistema di inviti con giudizio!
La domanda funzionalità vs bug riguarda la prioritizzazione: cerchiamo di correggere i bug rapidamente, specialmente se si tratta di bug di sicurezza! Ma in questo caso la funzionalità è la stessa di sempre ed è così per progettazione. Penso che dovremmo cambiarla, ma non è una cosa del tipo “molla tutto e correggila subito”.
Daremo tempo ad altri di esprimersi in modo da poter decidere la direzione che vorremmo prendere.
Potrebbe essere una modifica molto più complessa a seconda di come il guardian è coinvolto nei diversi elementi di questo processo, ma un’altra opzione, che dipenderebbe anche da 3, è:
Aggiungi una proprietà booleana agli inviti stessi per aggirare l’approvazione dell’utente. Questa proprietà sarebbe disattivata per impostazione predefinita e verrebbe esposta solo nell’interfaccia utente di creazione dell’invito quando must_approve_users è abilitato.
Modifica: In realtà, guardando di nuovo il codice a cui David ha fatto riferimento, suppongo che il guardian non sia affatto coinvolto nel decidere se un utente invitato debba essere approvato. Sembra che quella parte sarebbe una semplice sostituzione di invite.invited_by.staff? con qualcosa come invite.bypass_approval?
Comprendo appieno i tuoi vincoli di prioritizzazione. Suppongo che la nostra istanza si trovi in una situazione insolita, poiché tutte le istanze di Discourse che conosco provengono da organizzazioni che non hanno le rigide politiche di sicurezza a cui dobbiamo attenerci. Ad esempio, l’invito-only è stato un vincolo imposto dalla nostra organizzazione, la nostra istanza non potrebbe esistere con l’iscrizione autonoma. Con l’iscrizione autonoma sarebbe più facile, non avremmo bisogno di utilizzare gli inviti illimitati che possono “allentarsi”.
