BUG 5.200 a 5.2.004 - Módulo de Segurança

(Adesoft) #1

BUG 5.200 a 5.2.004 - Módulo de Segurança

O Campo senha do módulo de Segurança esta vindo com a senha em branco, sem o preenchimento dos (*****) com isto se o usuário não digitar a senha novamente ele acaba salvando a senha em branco.

Pois o tipo de campo senha (Mesmo usando em outros formulários) fica sempre em branco (Invisível) e se você faz uma consistência no campo, uma validação - if (empty ({senha})) ele sempre vai retornar que o campo esta em branco mesmo com o conteúdo do banco gravada.

Sugestão:
O Campo senha deveria ao gravar trazer o conteúdo preenchido totalmente exemplo:

Tamanho do campo 15 caracteres

Campo senha => Conteúdo => 12345 (Número de 1 a 5) Ocupando 5 dígitos do campo

Resultado para aparecer na tela dos usuários
Campos senha => Conteúdo => *************** => Estaria aparecendo os 15 caracteres preenchidos, porém a senha só seria 5 dígitos. Assim não teria como saber o tamanho da senha e o campo estaria sempre visível o seu preenchimento, evitando do usuário gravar a senha em branco como ocorre hoje.

Adeilson de Oliveira
THS do Brasil

(system) #2

Bom dia Adeilson.

Esse problema foi corrigido, e irá sair na próxima release.

(Adesoft) #3

BUG 5.2.000 a 5.2.005 - Módulo de Segurança

Nesta versão fizeram um gambiarra para ser masi fácil do que fazer o certo.

Na versão 5.2.005 foi criado um form separado para alteração de senhas, porém para quem já tem o módulo implantado não foi alterado o código para deixar a senha do form de usuários invisível.

Peço a NetMake como o release não consta o detalhamento do que foi alterado, liberar um How-To completo com os códigos e eventos para alterar na mão o form de usuários.

Para quem for adicionar pela primeira vez o módulo de segurança as alterações no form de usuários vem prontas.
Por isto creio que seria importante um comunicado, um arq. explicando as alterações detalhasdas que os desenvolvedores devem fazer, com os fontes e eventos para que a aplicação possa funcionar 100%.

Porém minha opnião fica a anterior, fazer o campo do tipo senha aparecer o conteúdo 100% preenchido seja com (*****) ou (…) como desejar porém visualizando 100% pois as comparações ficam melhor hoje o campo aparece vazio e algumas vezes a comparação com empty e ou outras funções não tem o êxito esperado.

At.

Adeilson de Oliveira

(Cleyton Euler) #4

Não testei, pois não uso o sistema de segurança nativo do SC.

Mas lendo seu relato, se o campo está em branco, faz uma validação para forçar o usuário a digitar uma senha, ou talvez forçar o campo a mostrar **** também funcione.

Para remediar enquanto a NM não apresenta a solução proposta.

(Adesoft) #5

BUG 5.2.00 a 5.2.005
Cleyton,

Agradeço a ajuda, porém o campo do tipo senha que é prórpio do SC, ele tem uma função que vc digita a senha ele preenche a senha digitada com (…) e após gravar ele apaga o conteúdo visual da senha, ficando o campo em branco, porém tem dados dentro dele.

O Problema é quando vc compara se o campo esta vazio com if (empty()) muitas vezes da problema pois o SC tem hora que reconhece que o campo tem dados e outras não ele diz que esta vazio, mais o conteúdo esta lá.

Por isto precisa ser alterado a forma de visualização deste tipo de campo, passando ele a ser preenchido completamente exmemplo:
Campo senha total de caracteres 10 digitos:=> Ao colocar senha 1 a 5 ele fica com 5 digitos preenchido => 12345
O SC grava 12345 e fica invisivel

Minha sugestão seria:
Campo senha total de caracteres 10 digitos:=> Ao colocar senha 1 a 5 ele fica com 5 digitos preenchido => 12345
O SC grava 12345 e preencha todo os 5 digitos faltando com (***) ficando:
********** => Assim ninguém fica sabendo o tamanho da senha, o (
) é uma representação podendo ser qualquer caracter como o (.) grande que é hoje.

At.

Adeilson de Oliveira

(Cleyton Euler) #6

Concordo com a sua sugestão!!!

Mas no formulário de trocar senha, coloque um label tipo, NOVA SENHA, fica intuitivo para o usuário que ele tem que digitar uma nova senha. Para ele conseguir trocar senha ele tem que ter feito login já com a senha antiga.

Pode ser mais um remédio. rsrsrs.

(weber) #7

eu nao encontrei nenhum bug nesse quesito nestas ultimas “migrações” updates

(miguell) #8

Pessoal na semana passada falei com o suporte sobre este problemas e me disserao que realmente é um bug doSC, e a solucao que encontrei junto com o Suporte foi a seguinte:
=> Ao entrar no cadastro do usuario gavar a senha que esta no banco em uma variavel;
=> no Evento OnBeforeUpdate fazer uma checagem se o campo senha estiver vazio
Campo saenha = [variave], ou se o campo senha for direferente da [variavel] ggravar campo senha por o mesmo foi alterado. segue o codigo.

if({tx_senha}==’’){
{tx_senha} = [var_senha];
}else{
{tx_senha} = md5({tx_senha});
}

(Cleyton Euler) #9

Então, é como eu estava conversando com o Adesoft. Uma validação resolveu.