Diferenciar maiúsculas no login e na senha

25/10/2013

0

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

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


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

Jair Souza

Responder

Posts

25/10/2013

Jair Souza

Verificando
Responder

27/10/2013

Jair Souza

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

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

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

Agradeço se puder ajudar.



Responder

27/10/2013

Joel Rodrigues

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?
Responder

28/10/2013

Jair Souza

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

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);
Responder

29/10/2013

Joel Rodrigues

Tente modificar o WHERE para o seguinte:
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.
Responder

29/10/2013

Jair Souza

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

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);
Responder

30/10/2013

Joel Rodrigues

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.
Responder

30/10/2013

Jair Souza

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

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);
Responder

04/11/2013

Jair Souza

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.
Responder

12/11/2013

Jair Souza

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

12/11/2013

Joel Rodrigues

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ó: [url]http://www.accessforums.net/queries/use-collate-statement-select-clause-1981.html[/url].
Responder

12/11/2013

[desativado] Gonçalves

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?
Responder

12/11/2013

Jair Souza

É 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.
Responder

12/11/2013

[desativado] Gonçalves

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.
Responder

12/11/2013

Jair Souza

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.
Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar