Pergunte ao barman: é correto fornecer credenciais de administrador do WordPress para a equipe de suporte do plug-in?

Não. Nada. Não. Não. Isso é um negativo. Sob nenhuma circunstância. Minha mãe não criou nenhum tolo. Poxa né. Não em sua vida. E as outras milhares de maneiras de dizer a qualquer pessoa que peça credenciais do site para se desanimar, até mesmo a equipe de suporte de plugins de uma empresa de desenvolvimento WordPress “confiável”.

Essa é a minha maneira de dizer que não confio em ninguém. Nem você deveria. No entanto, há casos em que é necessário fornecer permissões de administrador para a equipe de suporte de um plugin.

A edição de hoje da série Ask the Bartender é cortesia de um leitor chamado Niko. Como o texto inteiro tem mais de 1.000 palavras, vou simplesmente vincular a transcrição por meio de um arquivo .txt para quem quiser lê-lo na íntegra. Aqui no post, vou me ater aos bits vitais. Ou pelo menos as partes que eu quero abordar.

Um dos membros do grupo de Niko no Facebook deu início à discussão.

'Tudo bem enviar detalhes de FTP para um desenvolvedor de plugins para solucionar o problema que estamos tendo com o WooCommerce. Já fornecemos credenciais de administrador do WordPress.'

Esta é uma prática bastante normal no mundo WordPress, certo? Desenvolvedores de plug-ins ajudando em problemas e, se não puderem replicar um problema, eles precisam do acesso para verificar se é um problema de plug-in ou um problema de servidor e corrigir as coisas?

Ao longo dos anos, tenho visto isso se tornar uma prática mais comum. No entanto, não é uma prática que eu recomendo do usuário ou do desenvolvedor. Qualquer proprietário de site deve perguntar se confia na pessoa a quem está fornecendo credenciais. Se a resposta a essa pergunta for não, você tem a resposta para a primeira pergunta.

Em mais de uma década administrando uma loja de temas e plugins, nunca precisei de acesso de administrador ou FTP para lidar com uma questão de suporte. Não importava se era um plugin grande e complexo ou pequeno. Como eu era a única pessoa na empresa, também respondi pessoalmente a centenas de milhares de perguntas de suporte ao longo dos anos. Ainda assim, nem uma vez eu entrei no site de um usuário para ajudá-lo. Isso sempre me pareceu um problema de responsabilidade, mas também usei cenários como momentos de ensino sobre confiança e segurança.

Às vezes, os usuários me forneceram credenciais sem que eu pedisse. Muitas vezes, eles os postam em texto simples em fóruns, e-mail ou Slack (além disso, você nunca deve fazer isso). Se o código no local precisasse ser alterado, meus usuários executavam a tarefa sozinhos ou instalavam uma versão sem bugs do tema/plugin que entreguei.

Se eles não sabiam como executar uma tarefa via admin, FTP ou de outra forma, eu dedicava um tempo para ensiná-los. Sim, isso exigia mais energia em ambas as extremidades, mas acredito que fomos os melhores por isso. Mais de uma vez, esses momentos levaram alguns usuários ao caminho de se tornarem desenvolvedores, ou foi pelo menos um pequeno trampolim para eles. Eu continuo amigo de muitos deles hoje e estou orgulhoso que eles começaram com minha pequena loja WordPress solo.

Alguns casos foram mais ásperos do que outros. Muitas vezes, eu replicava sua configuração (plugins, tema, etc.) na minha máquina. Na maioria das vezes, isso me levou à solução – eu estava usando __doing_it_wrong() muito antes do WordPress apresentar a ideia. A longo prazo, consegui passar inúmeras correções de bugs upstream para outros desenvolvedores. Também fiz muitos amigos desenvolvedores assim.

Não tenho dúvidas de que a estrada que percorri foi a mais longa das duas. Houve momentos em que passei uma hora, duas ou até mais atendendo às necessidades de um usuário. Entrar em alguns de seus administradores do WordPress teria sido um curso mais rápido.

No entanto, meus usuários de temas e plugins nunca precisaram se preocupar se confiavam em mim o suficiente para fornecer esse nível de acesso. Além disso, não tive chance de quebrar acidentalmente o site deles fazendo alterações personalizadas.

Há momentos em que a equipe de suporte de um plugin realmente precisa de acesso? Provavelmente.

A pergunta original era em relação ao WooCommerce. É um dos plugins tecnicamente mais avançados existentes para o WordPress. Replicar a configuração de um usuário fora do local é mais complicado do que a maioria dos outros. Pode haver ocasiões raras em que você precise fornecer algum acesso, mas você nunca deve confiar em ninguém.

A segunda parte da pergunta de Niko gira em torno do Regulamento Geral de Proteção de Dados da União Europeia (GDPR) e dos dados do usuário. É uma parte vital de lidar com aqueles momentos em que você decide entregar as chaves do seu site.

Tudo bem, então aqui vem a questão depois de pensarmos no GDPR. Se esse desenvolvedor estiver fora da UE, você precisará anonimizar os dados do cliente e fazer um acordo de NDA com esse desenvolvedor ou empresa exato que está por trás do plug-in para que eles possam resolver as coisas.

Vou prefaciar isso com o habitual não sou advogado . No entanto, proteger os dados do usuário é sempre uma prioridade legal e ética em qualquer site que você administra, independentemente da jurisdição sob a qual você se encontra.

Nesses casos – novamente, raros – em que você precisa fornecer acesso ao seu administrador do WordPress, existem etapas que você pode seguir para proteger melhor seu site e seus dados. Independentemente da confiabilidade de um desenvolvedor ou de um membro da equipe de suporte, sempre há uma regra prática ao lidar com a segurança do site: não confie em ninguém e em nada.

O primeiro passo deve ser sempre ter um sistema de backup instalado. Na chance de que a equipe de suporte quebre algo, você desejará reverter o site de volta ao seu estado anterior.

Nunca forneça acesso completo no nível de administrador. Eu recomendo instalar e ativar um plug-in de gerenciamento de funções e recursos. Isso permitirá que você crie uma função personalizada para ajuda de suporte e limite as áreas do site às quais eles têm acesso. Você então criaria uma conta de usuário para eles com essa função. Depois de concluir o trabalho, exclua a conta.

Se você não quiser que eles vejam usuários registrados ou façam qualquer coisa com os dados do usuário, certifique-se de que sua função de usuário não tenha os seguintes recursos:

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

Existem muitos outros recursos de nível de administrador como edit_files , edit_plugins e edit_themes que você também deve evitar. Essencialmente, não permita a maioria das tampas da lista Administrador na documentação do WordPress.

Muito provavelmente, as equipes de plug-ins podem precisar de acesso ao recurso manage_options e qualquer um que seja personalizado para seu plug-in. Mesmo esses podem ser perigosos, mas esse backup que você implementa deve mitigar quaisquer problemas em potencial.

Quanto a uma senha de FTP? Confio em muito poucas pessoas com esse nível de acesso.

Esta resposta provavelmente parece que eu não acho que nenhuma loja ou desenvolvedor de plugins seja confiável. Honestamente, não conheço nenhum que tenha violado a confiança do usuário usando credenciais de login ou FTP dessa maneira. Por outro lado, não tenho como saber se o membro da equipe com quem estou falando planeja deixar o emprego à tarde e está disposto a queimar tudo pela manhã.

Eu também vi um punhado de casos em que um desenvolvedor apareceu para consertar algo, mas acabou quebrando o site ao longo do caminho. Os backups foram cruciais para resolver esses problemas.

Este post não pretende fazer com que desenvolvedores de plugins ou empresas pareçam não confiáveis. A maioria são pessoas boas apenas tentando ganhar a vida honestamente. No entanto, não confiar em nada é a segurança do site 101. É apenas a linha de base na qual os usuários devem operar. Se você entrar em qualquer interação com essa mentalidade, isso deve ajudá-lo a tomar decisões mais inteligentes caso a caso.