Non. Nada. Nan. Nan. C’est négatif. En aucun cas. Ma mère n’a pas élevé d’idiot. Zut non. Pas sur votre vie. Et, les milliers d’autres façons de dire à quiconque demande les informations d’identification du site de se déconnecter, 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 d’assistance d’un plugin.

L’épisode d’aujourd’hui de la Demandez au barman la série est une gracieuseté d’un lecteur nommé Niko. Parce que le texte entier compte plus de 1 000 mots, je vais simplement créer un lien vers le transcription via un fichier .txt pour ceux qui veulent le lire en entier. Ici, dans le post, je m’en tiendrai aux éléments essentiels. Ou du moins les parties que je veux aborder.

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

« Est-il possible 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 d’administrateur WordPress.’

C’est une pratique assez normale dans le monde WordPress, non ? Les développeurs de plugins aident à résoudre 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 cette pratique devenir de plus en plus courante. Cependant, ce n’est pas une pratique que je recommande de la part de l’utilisateur ou du 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 importe 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 répondu personnellement à 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 m’a toujours semblé être un problème de responsabilité, mais j’ai également utilisé des scénarios tels que des moments d’enseignement sur la confiance et la sécurité.

Les utilisateurs m’ont parfois fourni des informations d’identification sans que je leur demande. Souvent, ils les ont postés en texte brut dans des forums, des e-mails ou sur Slack (vous ne devriez jamais non plus le faire). Si le code sur site devait être modifié, mes utilisateurs effectuaient eux-mêmes la tâche ou installaient une version sans bogue du thème/plug-in 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 nécessitait plus d’énergie des deux côtés, mais je pense que nous étions les meilleurs pour cela. Plus d’une fois, ces moments ont conduit certains utilisateurs à devenir eux-mêmes des développeurs, ou c’était 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 en 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. Sur le long terme, j’ai pu transmettre d’innombrables corrections de bugs en amont à d’autres développeurs. Je me suis fait beaucoup d’amis développeurs de cette façon aussi.

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

Cependant, les utilisateurs de mon thème et de mon plugin 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 vraiment a besoin d’accéder? Probablement.

La question initiale concernait WooCommerce. C’est l’un des plugins les plus avancés techniquement existants pour WordPress. La réplication de la configuration d’un utilisateur hors site est plus délicate que la plupart des autres. Il peut y avoir peu fréquent moments où vous devez fournir un accès, mais vous ne devriez jamais faire confiance à personne.

La deuxième partie de la question de Niko porte sur le règlement général sur la protection des données (RGPD) de l’Union européenne et les 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.

Bon, voici le problème après avoir pensé au RGPD. S’il se trouve que ce développeur se trouve en dehors de l’UE, vous devrez alors anonymiser les données client et conclure un accord NDA avec le développeur ou la société exacte qui est derrière le plugin afin qu’ils puissent venir et réparer les choses.

Je vais commencer par 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 exploitez, quelle que soit la juridiction dont vous dépendez.

Dans les cas, encore une fois, rares, où vous devez fournir un accès à votre administrateur WordPress, vous pouvez prendre des mesures pour mieux protéger votre site et ses données. Quelle que soit la fiabilité d’un développeur ou d’un membre du personnel d’assistance, il existe toujours une règle de base en matière de sécurité de site Web : ne faire confiance à personne et ne faire confiance à rien.

La première étape devrait toujours être d’avoir un système de sauvegarde en place. Si le personnel d’assistance casse quelque chose, vous souhaiterez rétablir 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 plugin 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éeriez 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, rejetez la plupart des plafonds de la Liste des administrateurs dans la documentation WordPress.

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

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

Cette réponse sonne probablement comme si je ne pense pas que les magasins de plugins ou les développeurs soient dignes 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 quitter son emploi l’après-midi avec rage et est prêt à tout brûler le matin.

J’ai également vu une poignée de cas où un développeur est venu 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.

Cet article n’a pas pour but de donner l’impression que les développeurs de plugins ou les entreprises ne sont pas dignes de confiance. La plupart sont de bonnes personnes qui essaient simplement de gagner leur vie honnêtement. Cependant, ne faire confiance à rien est la sécurité du site Web 101. C’est simplement 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.


Source link