Demandez au barman : est-il acceptable de fournir des informations d'identification d'administrateur WordPress au personnel d'assistance du plugin ?

Non. Nada. Non. Non. C'est un point négatif. En aucun cas. Ma maman n'a élevé aucun imbécile. Heck non. Pas sur votre vie. Et, les milliers d'autres façons de dire à quiconque demande des informations d'identification pour le site de s'en aller, même le personnel de support des plugins d'une société de développement WordPress "de confiance".

C'est ma façon de dire que je ne fais confiance à personne. Vous non plus. Cependant, il existe des cas où il est nécessaire de fournir des autorisations d'administrateur au personnel de support d'un plugin.

L'épisode d'aujourd'hui de la série Ask the Bartender est une gracieuseté d'un lecteur nommé Niko. Étant donné que le texte entier compte plus de 1 000 mots, je ferai simplement un lien vers la transcription via un fichier .txt pour ceux qui souhaitent le lire en entier. Ici, dans le post, je m'en tiendrai aux éléments vitaux. Ou du moins les parties que je veux aborder.

L'un des membres du groupe Facebook de Niko a lancé la discussion.

'Est-il acceptable d'envoyer des détails FTP à un développeur de plugins pour résoudre le problème que nous rencontrons avec WooCommerce. Nous avons déjà fourni les informations d'identification de l'administrateur WordPress.'

C'est une pratique assez normale dans le monde WordPress, n'est-ce pas ? Les développeurs de plugins aident sur les problèmes, et s'ils ne peuvent pas reproduire un problème, ils ont besoin de l'accès pour pouvoir vérifier s'il s'agit d'un problème de plugin ou de serveur et résoudre les problèmes ?

Au fil des ans, j'ai vu cela devenir une pratique courante. Cependant, ce n'est pas une pratique que je recommande à l'utilisateur ou au développeur. Tout propriétaire de site doit demander s'il fait confiance à la personne à qui il donne des informations d'identification. Si la réponse à cette question est non, vous avez la réponse à la première question.

En plus d'une décennie de gestion d'une boutique de thèmes et de plugins, je n'ai jamais eu besoin d'un accès administrateur ou FTP pour traiter une question d'assistance. Peu importait qu'il s'agisse d'un plugin volumineux et complexe ou d'un petit. Parce que j'étais la seule personne dans l'entreprise, j'ai également personnellement répondu à des centaines de milliers de questions d'assistance au fil des ans. Pourtant, pas une seule fois je ne me suis connecté au site d'un utilisateur pour l'aider. Cela a toujours semblé être un problème de responsabilité pour moi, mais j'ai également utilisé des scénarios tels que des moments d'enseignement sur la confiance et la sécurité.

Les utilisateurs me fournissaient parfois des informations d'identification sans que je le demande. Souvent, ils les publiaient en texte brut dans des forums, des e-mails ou Slack (vous ne devriez jamais faire cela non plus). Si le code sur site devait être modifié, mes utilisateurs effectuaient la tâche eux-mêmes ou installaient une version sans bug du thème/plugin que j'avais remis.

S'ils ne savaient pas comment effectuer une tâche via l'admin, FTP ou autre, je prenais le temps de leur apprendre. Oui, cela a demandé plus d'énergie des deux côtés, mais je crois que nous en avons été meilleurs. Plus d'une fois, ces moments ont conduit certains utilisateurs à devenir eux-mêmes des développeurs, ou ce fut au moins un petit tremplin pour eux. Je reste ami avec beaucoup d'entre eux aujourd'hui et je suis fier qu'ils aient commencé avec ma petite boutique WordPress solo.

Certains cas étaient plus difficiles que d'autres. Plusieurs fois, je reproduisais leur configuration (plugins, thème, etc.) sur ma machine. La plupart du temps, cela m'a conduit à la solution - j'utilisais __doing_it_wrong() bien avant que WordPress n'introduise l'idée. À long terme, j'ai pu transmettre d'innombrables corrections de bogues en amont à d'autres développeurs. Je me suis aussi fait beaucoup d'amis développeurs de cette façon.

Je n'ai aucun doute que la route que j'ai parcourue était la plus longue des deux. Il y a eu des moments où j'ai passé une heure, deux ou même plus à répondre aux besoins d'un utilisateur. Entrer dans certains de leurs administrateurs WordPress aurait été un cours plus rapide.

Cependant, mes utilisateurs de thèmes et de plugins n'ont jamais eu à se soucier de savoir s'ils me faisaient suffisamment confiance pour fournir ce niveau d'accès. De plus, je n'avais aucune chance de casser accidentellement leur site en apportant des modifications personnalisées.

Y a-t-il des moments où le personnel d'assistance d'un plugin a vraiment besoin d'un accès ? Probablement.

La question initiale concernait WooCommerce. C'est l'un des plugins les plus avancés techniquement pour WordPress. Répliquer la configuration d'un utilisateur hors site est plus délicat que la plupart des autres. Il peut y avoir de rares moments où vous devez fournir un accès, mais vous ne devez jamais faire confiance à personne.

La deuxième partie de la question de Niko tourne autour du règlement général sur la protection des données (RGPD) de l'Union européenne et des données des utilisateurs. C'est un élément essentiel pour gérer les moments où vous décidez de remettre les clés de votre site Web.

D'accord, voici donc le problème après avoir pensé au RGPD. Si ce développeur se trouve en dehors de l'UE, vous devrez anonymiser les données client et conclure un accord NDA avec ce développeur ou cette entreprise qui est derrière le plugin afin qu'il puisse venir et réparer les choses.

Je vais préfacer ceci avec l'habituel je ne suis pas avocat . Cependant, la protection des données des utilisateurs est toujours une priorité légale et éthique sur tout site que vous gérez, quelle que soit la juridiction sous laquelle vous vous trouvez.

Dans les cas – encore une fois, rares – où vous devez fournir un accès à votre administrateur WordPress, vous pouvez prendre certaines mesures pour mieux protéger votre site et ses données. Indépendamment de la fiabilité d'un développeur ou d'un membre du personnel d'assistance, il existe toujours une règle d'or lorsqu'il s'agit de la sécurité d'un site Web : ne faire confiance à personne et à rien.

La première étape doit toujours être d'avoir un système de sauvegarde en place. Au cas où le personnel d'assistance casse quelque chose, vous voudrez remettre le site dans son état précédent.

Ne fournissez jamais un accès complet au niveau administrateur. Je recommande d'installer et d'activer un plug-in de gestion des rôles et des capacités. Cela vous permettra de créer un rôle personnalisé pour l'assistance et de limiter les zones du site auxquelles ils ont accès. Vous créerez ensuite un compte utilisateur pour eux avec ce rôle. Une fois qu'ils ont terminé leur travail, supprimez leur compte.

Si vous ne voulez pas qu'ils voient les utilisateurs enregistrés ou qu'ils fassent quoi que ce soit avec les données des utilisateurs, assurez-vous que leur rôle d'utilisateur n'a pas les capacités suivantes :

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

Il existe de nombreuses autres fonctionnalités de niveau administrateur telles que edit_files , edit_plugins et edit_themes que vous devriez également éviter. Essentiellement, interdisez la plupart des majuscules de la liste des administrateurs dans la documentation de WordPress.

Très probablement, les équipes de plugins pourraient avoir besoin d'accéder à la capacité manage_options et à toutes celles qui sont personnalisées pour leur plugin. Même ceux-ci peuvent être dangereux, mais cette sauvegarde que vous mettez en place devrait atténuer tout problème potentiel.

Quant à un mot de passe FTP ? Je fais confiance à très peu de gens avec ce niveau d'accès.

Cette réponse donne probablement l'impression que je ne pense pas qu'aucun magasin de plugins ou développeur ne soit digne de confiance. Honnêtement, je n'en connais aucun qui ait violé la confiance des utilisateurs en utilisant les identifiants de connexion ou FTP de cette manière. D'un autre côté, je n'ai aucun moyen de savoir si le membre du personnel à qui je parle envisage de se déchaîner l'après-midi et est prêt à tout brûler le matin.

J'ai également vu une poignée de cas où un développeur est intervenu pour réparer quelque chose mais a fini par casser le site en cours de route. Les sauvegardes étaient cruciales pour résoudre ces problèmes.

Ce message n'est pas destiné à faire paraître les développeurs de plugins ou les entreprises indignes de confiance. La plupart sont de bonnes personnes qui essaient juste de gagner leur vie honnêtement. Cependant, ne faire confiance à rien est la sécurité du site Web 101. Il s'agit simplement de la base dans laquelle les utilisateurs doivent opérer. Si vous entrez dans une interaction avec cet état d'esprit, cela devrait vous aider à prendre des décisions plus intelligentes au cas par cas.