No niente. No. No. Questo è un aspetto negativo. In nessuna circostanza. Mia mamma non ha cresciuto nessuno sciocco. Diamine, no. Non nella tua vita. E le altre migliaia di modi per dire a chiunque chieda le credenziali del sito di andare in fumo, anche il personale di supporto dei plug-in di una società di sviluppo WordPress “affidabile”.

Questo è il mio modo per dire che non mi fido di nessuno. Nemmeno tu dovresti. Tuttavia, ci sono casi in cui è necessario fornire le autorizzazioni di amministratore al personale di supporto di un plug-in.

La puntata di oggi del Chiedi al barista serie viene per gentile concessione di un lettore di nome Niko. Poiché l’intero testo è di oltre 1.000 parole, mi collegherò semplicemente al trascrizione tramite un file .txt per chi volesse leggerlo integralmente. Qui nel post, mi atterrò ai pezzi vitali. O almeno le parti che voglio affrontare.

Uno dei membri del gruppo Facebook di Niko ha dato il via alla discussione.

‘Va bene inviare dettagli FTP per uno sviluppatore di plugin per risolvere il problema che stiamo riscontrando con WooCommerce. Abbiamo già fornito le credenziali di amministratore di WordPress.’

Questa è una pratica abbastanza normale nel mondo di WordPress, giusto? Gli sviluppatori di plug-in aiutano a risolvere i problemi e se non possono replicare un problema, hanno bisogno dell’accesso in modo che possano verificare se si tratta di un problema di plug-in o di server e risolvere le cose?

Nel corso degli anni, ho visto questo diventare più di una pratica comune. Tuttavia, non è una pratica che consiglio né all’utente né allo sviluppatore. Qualsiasi proprietario del sito dovrebbe chiedere se si fida della persona a cui sta fornendo le credenziali. Se la risposta a questa domanda è no, hai la risposta alla prima domanda.

In oltre un decennio di gestione di un negozio di temi e plugin, non ho mai avuto bisogno dell’amministratore o dell’accesso FTP per affrontare una domanda di supporto. Non importava se si trattava di un plugin grande e complesso o di uno piccolo. Poiché ero l’unica persona in azienda, nel corso degli anni ho anche risposto personalmente a centinaia di migliaia di domande di supporto. Tuttavia, non una volta ho effettuato l’accesso al sito di un utente per aiutarlo. Mi è sempre sembrato un problema di responsabilità, ma ho anche usato scenari come momenti di insegnamento sulla fiducia e la sicurezza.

Gli utenti a volte mi hanno fornito le credenziali senza che me lo chiedessi. Spesso li hanno pubblicati in testo normale in forum, e-mail o Slack (inoltre, non dovresti mai farlo). Se il codice in loco doveva essere modificato, i miei utenti eseguivano l’attività da soli o installavano una versione priva di bug del tema/plugin che avevo consegnato.

Se non sapevano come eseguire un’attività tramite l’amministratore, FTP o altro, mi sono preso il tempo per insegnarglielo. Sì, ciò ha richiesto più energia da entrambe le parti, ma credo che siamo stati i migliori per questo. Più di una volta, quei momenti hanno portato alcuni utenti a diventare loro stessi sviluppatori, o almeno è stato un piccolo trampolino di lancio per loro. Rimango amico di molti di loro oggi e sono orgoglioso che abbiano iniziato con il mio piccolo negozio WordPress da solista.

Alcuni casi erano più difficili di altri. Molte volte, replicherei la loro configurazione (plug-in, temi, ecc.) Sulla mia macchina. La maggior parte delle volte, questo mi ha portato alla soluzione: stavo usando __doing_it_wrong() molto prima che WordPress introducesse l’idea. A lungo termine, sono stato in grado di passare innumerevoli correzioni di bug a monte ad altri sviluppatori. Ho anche fatto molti amici sviluppatori in questo modo.

Non ho dubbi che la strada che ho percorso sia stata la più lunga delle due. Ci sono stati momenti in cui ho dedicato un’ora, due o anche di più alle esigenze di un utente. Entrare in alcuni dei loro amministratori di WordPress sarebbe stato un corso più veloce.

Tuttavia, gli utenti del mio tema e del mio plugin non hanno mai dovuto preoccuparsi se si fidavano di me abbastanza da fornire quel livello di accesso. Inoltre, non avevo alcuna possibilità di rompere accidentalmente il loro sito apportando modifiche personalizzate.

Ci sono momenti in cui il personale di supporto di un plugin? veramente ha bisogno di accesso? Probabilmente.

La domanda originale riguardava WooCommerce. È uno dei plugin tecnicamente più avanzati esistenti per WordPress. La replica della configurazione di un utente fuori sede è più complicata della maggior parte degli altri. Ci potrebbe essere raro volte in cui è necessario fornire un accesso, ma non dovresti mai fidarti di nessuno.

La seconda parte della domanda di Niko ruota attorno al Regolamento generale sulla protezione dei dati (GDPR) dell’Unione Europea e ai dati degli utenti. È una parte vitale per affrontare quei momenti in cui decidi di consegnare le chiavi del tuo sito web.

Bene, ecco il problema dopo aver pensato al GDPR. Se questo sviluppatore si trova al di fuori dell’UE, allora dovresti rendere anonimi i dati dei clienti e stipulare un accordo NDA con lo sviluppatore o la società esatta che si trova dietro il plug-in in modo che possano intervenire e risolvere le cose.

Premetterò questo con il solito Non sono un avvocato. Tuttavia, proteggere i dati dell’utente è sempre una priorità legale ed etica su qualsiasi sito che gestisci, indipendentemente dalla giurisdizione in cui rientri.

In quei casi, anche in questo caso rari, in cui è necessario fornire l’accesso all’amministratore di WordPress, ci sono dei passaggi che potresti adottare per proteggere meglio il tuo sito e i suoi dati. Indipendentemente dall’affidabilità di uno sviluppatore o di un membro del personale di supporto, c’è sempre una regola pratica quando si ha a che fare con la sicurezza del sito Web: non fidarsi di nessuno e non fidarsi di nulla.

Il primo passo dovrebbe essere sempre avere un sistema di backup in atto. Nel caso in cui il personale di supporto rompa qualcosa, vorrai riportare il sito al suo stato precedente.

Non fornire mai l’accesso completo a livello di amministratore. Consiglio di installare e attivare un plug-in di gestione dei ruoli e delle capacità. Ciò ti consentirà di creare un ruolo personalizzato per l’assistenza e limitare le aree del sito a cui hanno accesso. Dovresti quindi creare un account utente per loro con questo ruolo. Una volta che hanno completato il loro lavoro, elimina il loro account.

Se non vuoi che vedano gli utenti registrati o che facciano qualsiasi cosa con i dati degli utenti, assicurati che il loro ruolo utente non abbia le seguenti capacità:

• create_users
• delete_users
• edit_users
• list_users
• promote_users
• remove_users

Ci sono molte altre funzionalità a livello di amministratore come edit_files, edit_plugins, e edit_themes che dovresti anche evitare. In sostanza, non consentire la maggior parte dei tappi dal Elenco degli amministratori nella documentazione di WordPress.

Molto probabilmente, i team di plug-in potrebbero aver bisogno di accedere a manage_options capacità e quelli personalizzati per il loro plugin. Anche quelli possono essere pericolosi, ma quel backup che metti in atto dovrebbe mitigare eventuali problemi.

Per quanto riguarda una password FTP? Mi fido di pochissime persone con quel livello di accesso.

Questa risposta probabilmente suona come se non pensassi che nessun negozio di plugin o sviluppatore sia affidabile. Onestamente, non ne conosco nessuno che abbia violato la fiducia degli utenti utilizzando le credenziali di accesso o FTP in questo modo. D’altra parte, non ho modo di sapere se il membro dello staff con cui sto parlando ha intenzione di lasciare il lavoro nel pomeriggio ed è disposto a bruciare tutto al mattino.

Ho anche visto una manciata di casi in cui uno sviluppatore è intervenuto per riparare qualcosa ma ha finito per rompere il sito lungo la strada. I backup sono stati fondamentali per affrontare questi problemi.

Questo post non ha lo scopo di far apparire inaffidabili gli sviluppatori o le aziende di plug-in. La maggior parte sono brave persone che cercano solo di guadagnarsi da vivere onestamente. Tuttavia, non fidarsi di nulla è la sicurezza del sito Web 101. È semplicemente la linea di base in cui gli utenti dovrebbero operare. Se entri in qualsiasi interazione con questa mentalità, dovrebbe aiutarti a prendere decisioni più intelligenti caso per caso.