Autenticação do cliente (quem faz?)

[Malcriado]

A cena é a seguinte:

Vc recebe um email do seu cliente pedindo para excluir imediatamente a conta dele.

Pois bem, como saber que foi realmente seu cliente quem pediu isso?

<span style="font-weight: bold">Alguns dirão: "Eu ligo para o cliente". </span>

Isso me soa como amadorismo. O que vc fará? Uma identificação de voz? Lembrará de todos os clientes? (então tem poucos)

<span style="font-weight: bold">Outros dirão: "Nós não cancelamos a conta de nenhum usuário".</span>

Ok, imagine então que o email pedia outra coisa. Uma alteração de senha do painel de controle (CPanel, Plesk, etc).

<span style="font-weight: bold">Ou ainda: "Eu peço a confirmação dos dados"</span>

Ah, essa resposta já é melhor, mas mesmo assim, que dados? Vc tem dados suficientes cadastrados para fazer uma verificação sólida? Endereço e CPF não dão garantia de nada.

<span style="font-weight: bold">E finalmente: "Qualquer solicitação deve ser feita através da abertura de um ticket no painel do cliente"</span>

Bingo! Essa me parece a melhor opção, pois o cliente tem que ser responsável por algum meio de autenticação que permita ao "autenticado" fazer alterações na sua conta.

Porém, vem o ponto onde eu queria chegar; Como a maioria dos usuários do WHMCS usam a importação dos emails em tickets, como saber que aquele ticket foi aberto realmente pelo cliente e não por outra pessoa enviando um email com o endereço do cliente verdadeiro como remetente (algo muito fácil de se fazer)?

Eu poderia enviar abrir um ticket através de um email setado com o endereço de um cliente como remetente, exigindo a exclusão da minha conta e voilá. Vai aparecer para a administração um ticket aberto pelo cliente pedindo o suicídio.

Sugstões?

[Valdecir]

No caso de uma solicitação de exclusão, eu peço sempre para que o cliente solicite o cancelamento do serviço através do próprio WHMCS, assim ele precisa estar autenticado para fazê-lo, o que confirma que é o cliente, ou alguém de confiança do mesmo que possui os dados de acesso (que são de responsabilidade do cliente, diga-se de passagem).

No caso da solicitação de alteração de login e senha dos Paineis WHM/cPanel. Eu efetuo a alteração e respondo ao chamado (os chamados só podem ser visualizados quando o cliente está logado no painel, ou no seu próprio e-mail). Quando você responde a um chamado, caso alguém mal intencionado tenha solicitado a alteração usando o e-mail do cliente como remetente, quem receberá o e-mail com a nova senha será o próprio cliente no e-mail correto, que já terá então, acesso a nova senha (gerada por nós. Nunca altere uma senha para uma que seu cliente tenha solicitado. Sempre gere uma senha aleatória internamente, informe-a ao cliente, e peça que ele mesmo a altere para qualquer uma que desejar).

Esses são os procedimentos que eu adoto.

[Malcriado]

Olá Valdecir,

entendi seus procedimentos. E quanto a alteração de senhas, a sua abordagem de que o ticket com a senha é enviado apenas para o email cadastrado faz sentido. Porém esta é uma situação específica que exige um retorno da informação. Mas e se o pedido for algo como excluir uma determinada conta de email, uma determinada instalação do fantástico ou mesmo uma alteração na zona de DNS?

Essas são situações que não precisam de um retorno de informação.

[Valdecir]

Mas esses procedimentos o cliente tem acesso, e ele mesmo pode fazê-lo. Indique os passos para que seja executado por ele próprio e não terá nenhum tipo de problema.

[Malcriado]

Tem razão novamente.

Mas e na alteração de zona de DNSs? Ele não tem acesso a isso no CPanel. E mesmo nos casos anteriores, mesmo que o falso-cliente não consiga a senha do Cpanel (ou do email), o simples fato de ter essa senha alterada já é passível de transtornos com o cliente verdadeiro.

O que quero dizer é que a importação de emails como tickets, pode gerar complicações se o critério de validação do pedido for a abertura de um ticket.

Porém, pensando sobre o assunto, cheguei a uma conclusão simples e ao que me parece, definitiva.

Para quem quer utilizar a importação de emails para tickets para atendimento e também utilizar a abertura de um ticket como validação para um pedido autêntico, basta criar um departamento específico para isso que não faça a conversão de emails em tickets (por exemplo, "intervenção"). Para este departamento, abrir um ticket só é possível através do acesso ao painel do cliente.

Então, para facilitar as coisas, o cliente continua podendo enviar emails que serão convertidos em tickets. Este serão usados para atendimento e demais finalidades, exceto alterações na conta de qualquer natureza. Para isso, ele tem que abrir um ticket no dpto "intervenção" solicitando o que ele deseja (alteração de senha, etc). E como este ticket só pode ser aberto através do painel do cliente, está aí a sua autenticação.

Bingo?

[Valdecir]

Eu particularmente nunca tive problemas desse gênero que mencionou. Mas creio que caso alguém queira evitar algo neste sentido, esta seja sim uma solução válida.

[Malcriado]

Valeu Valdecir.

E obrigado por ter participado.

[Ostrock]

Malcriado,

O ideal é que seja previsto no contrato de serviços como serão tratadas ocorrências como essas que trazem riscos para a empresa, assim, se o cliente quiser cancelar a hospedagem, uma instalação no fantástico ou trocar de senha, como exemplificado, ele saberá exatamente quais o que e de que forma fazer.

Att.

Guilherme H. S. Ostrock

[AngelCosta]

Não li as outras respostas.

Mas solicitações sérias eu sempre presto atenção ao e-mail utilizado. NO MÍNIMO, deve ser o mesmo que consta em banco de dados. Depois vc valida o resto.

[Malcriado]

Mas aí é que tá Angelica,

é possível enviar emails configurados para aparecer outro endereço qualquer como remetente.