Array
(
)

Diferenciar maiúsculas no login e na senha

Jair Souza
   - 25 out 2013

Para diferenciar maiúsculas no login e na senha montei estes dois códigos, mas nenhum funciona, o que está errado ?
#Código

OleDbCommand comando = new OleDbCommand("SELECT * FROM Funcionario Where Login = '@Login' And Senha = '@Senha' COLLATE Latin1_General_CS_AS", conexao);

#Código
OleDbCommand comando = new OleDbCommand("SELECT * FROM Funcionario Where Login COLLATE Latin1_General_CS_AS = '" + @Login.Trim() +"' And Senha COLLATE Latin1_General_CS_AS = '" + @Senha.Trim() + "', conexao);

Jair Souza
   - 25 out 2013

Verificando

Jair Souza
   - 27 out 2013

Com o primeiro código dá o erro abaixo :

http://www.uploaddeimagens.com.br/imagens/erro_colate_1-png

...e osegundo nem consegui acertar dentro do código.

Agradeço se puder ajudar.

Joel Rodrigues
   - 27 out 2013

O segundo está bem errado, esqueça ele.
Vamos trabalhar no primeiro. Comece removendo as aspas simples que tem em volta dos parâmetros e teste novamente.

Ah, qual banco você está usando?

Jair Souza
   - 28 out 2013

O banco é ACCESS.
Mesmo tirando as aspas dá o mesmo erro, o código está assim :

#Código

OleDbCommand comando = new OleDbCommand("SELECT F.Perfil, P.Descricao FROM Funcionario AS F " + " INNER JOIN Perfil AS P ON F.Perfil = P.IDPerfil Where F.Login = @Login And F.Senha = @Senha COLLATE Latin1_General_CS_AS", conexao);

Joel Rodrigues
   - 29 out 2013

Tente modificar o WHERE para o seguinte:
#Código

Where F.Login COLLATE Latin1_General_CS_AS= @Login COLLATE Latin1_General_CS_AS And F.Senha COLLATE Latin1_General_CS_AS = @Senha COLLATE Latin1_General_CS_AS


Se não der, tente tirar o collate que fica depois dos parâmetros, deixando apenas depois dos campos.

Jair Souza
   - 29 out 2013

Alterei para as duas formas, e nenhuma das duas funcionou, continua dando o mesmo erro.

#Código

OleDbCommand comando = new OleDbCommand("SELECT * FROM Funcionario AS F" + "INNER JOIN Perfil AS P ON F.Perfil = P.IDPerfil Where F.Login COLLATE Latin1_General_CS_AS = @Login F.Senha COLLATE Latin1_General_CS_AS = @Senha ", conexao);

Joel Rodrigues
   - 30 out 2013

Cara, só agora reparei que falta um espaço depois do "F" (apelido da tabela). Ponha aí para ver se não é isso que está bagunçando.

Jair Souza
   - 30 out 2013

Não resolveu...com esta linha exatamente como está tirando somente a parte do "COLLATE Latin1_General_CS_AS", faz o login normal, mas sem diferenciar maiusculas, é alguma detalhe ligado diretamente ao COLLATE...

Coloquei o COLLATE no campo e no parâmetro, somente no campo e depois somente no parâmetro, entre parênteses e sem parenteses...e nada

#Código

OleDbCommand comando = new OleDbCommand("SELECT * FROM Funcionario AS F " + "INNER JOIN Perfil AS P ON F.Perfil = P.IDPerfil Where F.Login COLLATE Latin1_General_CS_AS = @Login F.Senha COLLATE Latin1_General_CS_AS = @Senha ", conexao);

Jair Souza
   - 04 nov 2013

E aí pessoal !
Alguma dica ?
Eu já tentei quase tudo de orientações pesquisadas na net, menos uma que desse certo.
O que eu acho estranho não ter algo objetivo para este caso, pois me parece que todo login tem por obrigação diferenciar maiúsculas e acentos.

Jair Souza
   - 12 nov 2013

Bom dia, pessoal !
Realmente não encontro nada na net que solucione este problema...
Devo desistir ?
Ninguem tem uma idéia ?

Joel Rodrigues
   - 12 nov 2013

Amigo, confesso que não respondi mais porque eu realmente nem sabia o que dizer. Nunca passei por tal situação. Mas pesquisando agora, encontrei o seguinte tópico em que o pessoal desencoraja bastante o cara que fez a pergunta, dizendo que não dá pra fazer. Veja só: http://www.accessforums.net/queries/use-collate-statement-select-clause-1981.html.

Dvm.lc.ledcrash
   - 12 nov 2013

Pessoal,

tanto o mecanismo do JET (Access) quanto o mecanismo do SQL Server não diferenciam maiusculas de minusculas e nem caracteres acentuados de não acentuados (dependo do collation claro).

Mas a pergunta que fica é porque você tem que diferenciar maiusculas e minusculas no login e senha?

Por acaso você estaria permitindo, por exemplo, um usuário Teste e um usuário tesTe? Seriam diferentes para sua aplicação?

Jair Souza
   - 12 nov 2013

É que eu gostaria que quando o usuário fizer o login, tenha que digitar exatamente como foi cadastrado, mas no momento se digitar João ou joão é permitido o acesso.

Dvm.lc.ledcrash
   - 12 nov 2013

Então, vai de cada um e das premissas de seu projeto mas, um sistema de autenticação por usuário e senha, por si só, não é a maneira mais segura de se fazer autenticação de um usuário mas, muitas vezes, é o que podemos fazer.

Já que não há outro jeito e precisa ser assim (não importando o motivo), a força da sua autenticação (ainda que esteja vulnerável a uma infinidade de tipos de ataques) está na maneira de guardar e verificar a senha.

Veja, imagino que o username na sua aplicação seja a chave da tabela. Se for, não faz sentido diferenciar Joao de joAo. Para o banco de dados, conforme exposto, será a mesma coisa e se você cadastrar outro JOao, vai haver problema de chave duplicada.

O que eu sempre faço, nesses casos, é colocar uma chave composta como, por exemplo, o e-mail e o username. Deste modo, fica mais difícil eu ter um username Joao com e-mail joao@dominio.com.br

Neste caso, o e-mail dele me ajuda a deixar o usuário quase que ÚNICO. Outra coisa boa a fazer é usar o CPF como username ou parte da chave composta. Afinal, CPF é um dos poucos documentos federais garantido de ser único.

Para proteção da senha, eu sempre guardo um HASH da mesma. Me avisa se não souber o que é e como computar o hash que eu te explico. Isto pode ser feito tanto no código da aplicação quanto no banco de dados. Como uma função HASH retorna a senha "protegida" e não pode ser revertida, ou seja, com o resultado do HASH eu não chego na senha, eu guardo o resultado do HASH no banco, no campo da senha, e toda vez que o usuário informa a senha dele, eu tiro o HASH novamente e verifico com o que está gravado no banco.

Deste modo, nem eu nem ninguém consegue saber o que o usuário digitou.

Claro que, você estará com isto vulnerável a ataques por MiTM (Man in The Middle) onde eu consigo facilmente capturar a senha do usuario (o HASH mesmo) e usá-lo mais tarde para autenticar e ganhar acesso aos dados dele. Existem técnicas para proteger contra estes tipos de ataques, configurações de servidor e, infelizmente, mudar drasticamente o seu código de autenticação.

Jair Souza
   - 12 nov 2013

Bom então parece mais coerente para um aplicativo simples, criar um código para verificar se já tem “Joao” cadastrado e também verificar se este “Joao” Já está logado.
Se já tem “Joao” cadastrado não cadastra outro.
Se já está logado não logar outra vez.
E deixar digitar o “Joao” como quiser.

Joel Rodrigues
   - 12 nov 2013

Amigo, geralmente o campo login não é case sensitive, ou seja, não diferencia maiúsculas de minúsculas. Isso geralmente é aplicado apenas no campo senha.

Dvm.lc.ledcrash
   - 12 nov 2013

Isso mesmo Jair. Fica mais fácil assim não é mesmo?

Jair Souza
   - 12 nov 2013

Com certeza, mas para a senha parece importante diferenciar ?

Joel Rodrigues
   - 12 nov 2013


Citação:
Com certeza, mas para a senha parece importante diferenciar ?
Para a senha é fundamental que seja diferenciado, inclusive alguns sistemas requerem que a senha seja composta por letras maiúsculas e minúsculas (além de caracteres especiais e numéricos, em alguns casos).

Jair Souza
   - 12 nov 2013

...sim, mas como fazer ? Já que COLLATE Latin1_General_CS_AS não dá.
Partindo do que já tenho nesta linha :

#Código

OleDbCommand comando = new OleDbCommand("SELECT * FROM Funcionario F " + "INNER JOIN Perfil AS P ON F.Perfil  = P.IDPerfil Where [F.Login] = @Login and [F.Senha] = @Senha and F.Situacao = true", conexao);