Sou novato em java, e gostaria de saber como eu faria para pegar os dados de um JTextField e um JpasswordField e validar atraves de dados cadastrados em um banco, a conexao ja esta feita, so queria saber como fazer esta validacao, estou utilizando o mysql 5.0 alpha.Para pegar os dados:
String user = JTextField.getText();
String pw = JPasswordField.getText();Armazene isso em uma variavel e faça um select com ela no banco.
"select * from usuarios where nome = " + user + " and password = " + pwDepois dê uma olhada na classe PreparedStatement, nela vc consegue parametrizar a sua query, fica melhor do que fazer concatenações 
Valeu, cara, meu ajudou bastante
Até mais
Tamo junto!
[quote=andre_a_s]Armazene isso em uma variavel e faça um select com ela no banco.
[code]"select * from usuarios where nome =
[/quote]
Aham, por deformação profissional, sinto-me no dever de comunicar que você DEVE usar PreparedStatement nesse caso; não use a concatenação de strings, senão abrirá um buraco de segurança bastante grande para caber um caminhão dentro.
Suponha que alguém tenha entrado com o seguinte usuário:
juca’ –
O ‘–’ é o comentário padrão SQL ANSI. Modifique isto para seu SQL preferido.
Nesse caso não será validada a senha, pois a query será:
select * from usuários where nome = ‘juca’ –’ and password=’’
(você viu que o pedaço ‘and password’ foi comentado.)
Esse erro é muito comum (faz parte dos 10 mais), por favor nunca faça isso no caso de usuários e senhas. Na verdade nunca guarde uma senha em um banco de dados, se possível - guarde apenas o “digest” (MD5 ou SHA-1).
" + user + "’ and password =
[/quote]
Aham, por deformação profissional, sinto-me no dever de comunicar que você DEVE usar PreparedStatement nesse caso; não use a concatenação de strings, senão abrirá um buraco de segurança bastante grande para caber um caminhão dentro.
Suponha que alguém tenha entrado com o seguinte usuário:
juca’ –
O ‘–’ é o comentário padrão SQL ANSI. Modifique isto para seu SQL preferido.
Nesse caso não será validada a senha, pois a query será:
select * from usuários where nome = ‘juca’ –’ and password=’’
(você viu que o pedaço ‘and password’ foi comentado.)
Esse erro é muito comum (faz parte dos 10 mais), por favor nunca faça isso no caso de usuários e senhas. Na verdade nunca guarde uma senha em um banco de dados, se possível - guarde apenas o “digest” (MD5 ou SHA-1).
" + pw + "
[/quote]
Aham, por deformação profissional, sinto-me no dever de comunicar que você DEVE usar PreparedStatement nesse caso; não use a concatenação de strings, senão abrirá um buraco de segurança bastante grande para caber um caminhão dentro.
Suponha que alguém tenha entrado com o seguinte usuário:
juca’ –
O ‘–’ é o comentário padrão SQL ANSI. Modifique isto para seu SQL preferido.
Nesse caso não será validada a senha, pois a query será:
select * from usuários where nome = ‘juca’ –’ and password=’’
(você viu que o pedaço ‘and password’ foi comentado.)
Esse erro é muito comum (faz parte dos 10 mais), por favor nunca faça isso no caso de usuários e senhas. Na verdade nunca guarde uma senha em um banco de dados, se possível - guarde apenas o “digest” (MD5 ou SHA-1).
"[/code]
[/quote]
Aham, por deformação profissional, sinto-me no dever de comunicar que você DEVE usar PreparedStatement nesse caso; não use a concatenação de strings, senão abrirá um buraco de segurança bastante grande para caber um caminhão dentro.
Suponha que alguém tenha entrado com o seguinte usuário:
juca’ –
O ‘–’ é o comentário padrão SQL ANSI. Modifique isto para seu SQL preferido.
Nesse caso não será validada a senha, pois a query será:
select * from usuários where nome = ‘juca’ –’ and password=’’
(você viu que o pedaço ‘and password’ foi comentado.)
Esse erro é muito comum (faz parte dos 10 mais), por favor nunca faça isso no caso de usuários e senhas. Na verdade nunca guarde uma senha em um banco de dados, se possível - guarde apenas o “digest” (MD5 ou SHA-1).
Bom… o grande thingol está certo mais uma vez…rs
Fiz concatenando pra vc entender melhor 
Dá próxima vez eu coloco de cara o PreparedStatement :mrgreen:
E nunca use em nenhum outro caso, tambem, pq tem outro ataque de SQL Injection possivel numa query qualquer:
"SELECT * FROM products WHERE product = " + product + ";"Basta enfiar um “;” esquisito ali, e da pra fazer isso:
SELECT * FROM products WHERE product = 10; DROP TABLE products;Oops.
É por isso que muitas instituições bancárias normalmente requerem que se use stored procedures, em vez de comandos SQL comuns, para acesso a suas bases no Oracle ou DB2.
Os seus DBAs acreditam que ficam um pouco mais imunes a erros comuns de codificação - as tabelas dos bancos somente podem ser acessadas por stored procedures, e o usuário da aplicação somente pode usar um conjunto limitado de stored procedures. Isso amarra as mãos da gente um monte (para fazer qualquer alteraçãozinha você precisa submeter a nova stored procedure ao DBA, e normalmente ele já está ‘até aqui’ com essas alterações), mas é o preço que se paga por um pouco mais de segurança.
O problema do ‘drop table’ pode ser minimizado fazendo-se com que a aplicação rode com um usuário que não tem permissão de DDL (ou seja, nada de usar “sa” com senha “”, que é o padrão do MS SQL Server, Sybase e do HSQLDB). Mas nada impede de o cara fazer algo como ‘delete from products’ nessa query…