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

Que tal ter acesso a um e-book gratuito que vai te ajudar muito nesse momento decisivo?

Ver ebook

Recomendado pra quem ainda não iniciou o estudos.

Eu quero
Ver ebook

Recomendado para quem está passando por dificuldades nessa etapa inicial

Eu quero

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

Aceitar