A seguito di un’indicazione di argomento fuori tema nel thread di Discobot, mi chiedo se la community di Discourse voglia discutere se consentire l’impersonificazione degli utenti con un singolo clic sia accettabile o se possa essere qualcosa da riservare a scenari specifici.
Dal mio punto di vista, è come usare l’IP o l’ID di un’altra persona. Sono comportamenti non allineati all’etica o alla morale (prima che legali o illegali).
Penso che lo stesso valga per l’impersonificazione come soluzione “one-click”, dove gli amministratori potrebbero pubblicare come altri utenti con un singolo clic.
Voglio dire, cambiare alcune cose in Discourse richiede di entrare manualmente nell’app, usare Postgres e lavorare sui dati con molte query.
Perché l’impersonificazione è così facile, quando coinvolge un thread con molteplici prospettive e diversi interessi legali?
Questo probabilmente non è noto alla maggior parte degli utenti e tutti sappiamo che gli amministratori possono accedere al database e cambiare le cose, ma è totalmente diverso dal cliccare un pulsante e pubblicare come un altro utente.
Gli amministratori possono sospendere e bannare gli utenti se qualcosa di negativo sta accadendo sul forum e sono legalmente responsabili del sito web.
Come sviluppatore, Impersonate è una funzione assolutamente brillantemente utile che aiuta nel processo di sviluppo, in modo tale che io possa uscire rapidamente da un ruolo di amministratore ed entrare nel ruolo di un nuovo utente per verificare cosa vedrebbe…
Penso che il punto che si sta sollevando sia che l’impersonificazione facile (e silenziosa) potrebbe violare le aspettative, almeno in alcune comunità.
Non dovremmo considerare questo come una questione legale, ma come una questione di policy e cultura, ed è forse il tipo di policy in cui un amministratore del sito potrebbe scegliere un approccio o un altro.
A volte è utile impersonificare, ma forse la persona in questione dovrebbe ricevere una notifica. Forse in molti casi, la persona in questione potrebbe approvare una richiesta di impersonificazione.
A dire il vero, secondo me la funzionalità non è necessaria e dovrebbe essere rimossa. Ma sono sicuro che il team abbia delle ragioni per cui è presente. Ad esempio, passare a un account utente di test.
Per quanto riguarda la funzionalità utilizzata per impersonificare e postare come un altro utente, almeno pubblicamente si potrebbe semplicemente usare 3 click per cambiare proprietario.
In conclusione, avere solo amministratori scelti bene.
Questo potrebbe essere problematico poiché alcuni amministratori mantengono solo l’interfaccia come nel caso di @pfaffman con i clienti. Poiché tutti gli amministratori hanno permessi completi ma non usano cose al di fuori del loro lavoro. Come menzionato, bisogna controllare le leggi della propria regione; tuttavia, potrebbe essere necessario fare attenzione ai viaggi.
Creare l’API proposta per concedere a un utente funzioni di amministratore parziali di cui un designer/manutentore ha bisogno.
Vero, ma questo potrebbe essere fatto usando specificamente account di test. È qui che si arriva all’integrità dell’utente finale. Questo potrebbe essere, come suggerisce l’OP, un uso abusato e corrotto.
Mi ricorda l’avviso in Linux quando viene utilizzato per la prima volta il comando sudo:
Ci auguriamo che abbiate ricevuto la solita lezione dall'Amministratore di Sistema locale. Di solito si riduce a queste tre cose:
#1) Rispetta la privacy altrui.
#2) Pensa prima di digitare.
#3) Da un grande potere derivano grandi responsabilità.
Cioè, quando si utilizza Impersonate per la prima volta, o ogni volta, un amministratore potrebbe ricevere un avviso cliccabile, con un messaggio sul rispetto della privacy e sull’agire con integrità.
La funzione impersonate è una cosa buona se ci si pensa un attimo, ma non solo per le ragioni già menzionate.
Impersonate registra il suo utilizzo nel log dell’amministratore. Certo, un amministratore potrebbe eliminare la voce con la console rails o tramite una query SQL diretta in Postgres, ma ciò lascia la propria traccia (un buco negli ID del log che altro personale vedrà se lo cerca).
La mancanza di impersonate incoraggerebbe attivamente gli amministratori ad abusare dell’alternativa molto più sinistra che non verrà registrata, e sospetto che qualsiasi sviluppatore che legga ciò che ho appena scritto abbia già capito cosa sto per dire.
Vuoi avere una singola voce di log facilmente nascosta e persino fatta mesi in anticipo in modo che altro personale del forum non associ le due cose? Crei una chiave API per tutti gli utenti. 1 voce di log, e fai quello che vuoi come chiunque tu voglia quando vuoi, e a meno che non sia qualcosa che normalmente verrebbe registrato per l’utente che stai impersonando, non lascerebbe alcuna traccia.
Spesso si tratta di account di test in un ambiente di sviluppo, ma la configurazione di account di test in un ambiente di sviluppo richiede lavoro aggiuntivo. Questo evita di dover disconnettersi e riconnettersi, il che rallenta il flusso di lavoro ed è particolarmente fastidioso dover impostare password multiple, il che non è un’esperienza piacevole, rallenta e non aggiunge alcun valore in fase di sviluppo. Con Impersonate devi solo ricordare la password dell’amministratore.
Sto semplicemente illustrando un ulteriore vantaggio di questa funzionalità per questo specifico caso d’uso.
Gli account di test richiedono davvero poco tempo per essere creati e, in questa idea, sarebbero una parte standard dell’installazione di Discourse, proprio come Discobot e il sistema. La funzione “Impersonate” verrebbe mantenuta, salvata, funzionerebbe solo con, ad esempio, 3 o 4 account null di test che potrebbero essere modificati per simulare utenti di vari livelli.
Come è stato detto, persone con alti valori e integrità potrebbero non usare Impersonate per scopi nefasti. Sebbene l’uso sia allettante, nondimeno. Inoltre, se i membri di un sito sapessero che l’amministratore potrebbe usare il loro account per impersonarli, potrebbero perdere la fiducia nella piattaforma. Attualmente, impersonate si basa esclusivamente sull’integrità e non ha soluzioni alternative, a differenza di come “Encrypt Plugin” risolve i problemi degli utenti di un forum Discourse per rendere i PM/DM privati come gli utenti di un forum si aspettano, a meno che non sia chiaramente specificato che DM/PM non sono sicuri e privati come funzionalità attesa da una community. Sul lato positivo, ho chiesto specificamente se Impersonate potesse essere utilizzato per aggirare Encrypt Plugin, al che Sam ha spiegato e confermato che non poteva aggirare la protezione poiché si tratta di crittografia end-to-end.
Non è vero. Creare utenti di test ogni volta è una seccatura. Spesso creo nuove installazioni di sviluppo ed eseguo i fixture di sviluppo per comodità. (Quegli utenti con fixture non hanno password note, per quanto ne so) Quindi devo solo aggiungere un account amministratore e l’impersonificazione mi permette di passare dall’interfaccia utente in modo gradevole. Lavoro fatto.
Sono un po’ perplesso dalla tua negatività qui… Stavo semplicemente complimentandomi con la piattaforma per avere una funzionalità utile che uso regolarmente nel mio lavoro, ora stai attaccando questa funzionalità e il mio approccio con l’obiettivo di cosa? Di renderci la vita più difficile? Non sono sicuro di apprezzarlo molto!
Qual è veramente il problema con la funzionalità “impersonare”? perché state creando un problema dal nulla? comunque, questa è piuttosto utile e anche le grandi aziende tecnologiche utilizzano queste funzionalità se parliamo di privacy, allora l’amministratore può vedere tutto e può fare qualsiasi cosa con le cose del sito, Google, Facebook e tutte le grandi aziende tecnologiche lo fanno. non è niente di nuovo comunque.
E perché uno sviluppatore dovrebbe creare un account se il problema è dal lato dell’utente? In quei casi, questa funzionalità è piuttosto utile. Se hai un problema, allora non usarla.
Non sto attaccando affatto. Sto semplicemente sottolineando che si tratta di una funzionalità facilmente abusabile che può creare una miriade di problemi. Integrare account di test per l’uso diretto risolve il potenziale uso improprio non rendendola disponibile. Per quanto riguarda la creazione di un account di test. Ho aperto una seconda scheda, creato un account con un indirizzo email fittizio e sono tornato al mio account di amministratore effettuato l’accesso e validato.
Impersonate è sicuramente uno strumento utile che, se gli account di test predefiniti o un’opzione di amministrazione all’interno del pannello di amministrazione potessero creare account nulli che possono essere utilizzati con Impersonate. Chiuderebbe il potenziale uso improprio.
Come menzionato, se una community viene a conoscenza del fatto che gli account dello staff possono impersonarla, potrebbe non fidarsi della piattaforma della community.
Da quello che ho letto di te e di un sacco di altre persone fantastiche qui, non farebbero mai un uso improprio della funzionalità. Ma avere la funzionalità aperta di questa funzionalità potrebbe rendere le community meno fiduciose nei confronti di Discourse come piattaforma di forum.
Una discussione aperta non dovrebbe essere vista come negativa, ponderando pro e contro.
Il plugin Sam’s Encrypt impedisce ad Admin e Mod di visualizzare DM/PM, proprio come le app come Whatsapp pubblicizzano che non possono visualizzare le conversazioni a meno che non vengano invitate. Quindi questo chiude la funzione di visualizzazione DM/PM che potrebbe essere vista come una violazione della privacy prevista che non è chiaramente indicata come non veramente privata.
Questo è totalmente irrilevante. Se vuoi davvero leggere le comunicazioni private degli utenti, come amministratore puoi dare un’occhiata al database (a meno che tu non abiliti la crittografia).
Come proprietario di un sito web, hai in ogni caso accesso a tutto, puoi apportare qualsiasi modifica desideri, attivare e disattivare la crittografia, qualunque cosa.
Quando utilizzi un sistema di terze parti come utente, non hai alcun controllo diretto su ciò che le persone possono fare con i tuoi dati.
In ogni caso, non sto discutendo della Produzione, il mio punto era solo dire che questa funzionalità ha i suoi vantaggi anche nello Sviluppo e sono facili da dimostrare.
Quindi, dalla mia prospettiva, +1 su questo. Ora sono troppo impegnato per discutere ulteriormente. Buona giornata.
Allora non usare Google, Facebook, Microsoft e tutti gli altri dato che lo fanno tutti. Non dicono apertamente che possono “impersonarti”. Possono fare tutto ciò che puoi immaginare ma, nonostante ciò, ti fidi di loro e li usi ancora sapendo che possono fare qualsiasi cosa, quindi non so quale sia veramente il problema, amico. Forse sei preoccupato per i tuoi moderatori e amministratori del forum, ma comunque tutte le azioni vengono registrate se un amministratore utilizza la funzione “impersonificazione”. Quindi non riesco a capire qual è il problema. Se questa funzione fosse problematica, il team di Discourse non l’avrebbe inserita in primo luogo.
Il che, ovviamente, ha un suo merito. Ma avere questa disponibilità in un ambiente di produzione è rischioso.
Quindi, ciò che potrebbe essere ottimo sarebbe, come per altre funzionalità, avere questa funzione modificata in modo che sia necessario attivarla nel server Root.
Vedo come possa avere valore in un ambiente di Sviluppo, poiché gli utenti lì sono probabilmente consapevoli che si tratta di un ambiente di test.
Ho già menzionato l’uso della crittografia per chiudere quella funzione aperta.
