This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
okay..it works now after closing all resources..
but is it required to close all resources..?
i mean when i wan not closing resources, it was not redirecting me to success page, and login page again(if user id password is wrong)..
but now it's work..
also can you tell me, when user id and passwords are wrong, i need to redirect it to login page again with message("username and password wrong"), how can i do this??
i can use jsp and servlet.
i think it can be done using param tag, but don't know how..?
the API docs explain how you should be using a prepared statement, you have just taken your old statement string and used it in exactly the same way, so it isn't any safer in a prepared statement that a normal statement.
your still not using prepatred statements properly, and this is a very vunerable screen, it takes no skill to hack the login screen
but how, what i am doing wrong??
is there anything else also which i have to take care, even after using prepared statement??
Wendy and Jan have warned you about the vulnerabilty of your approach to SQL injection, which you can fix by using bind variables for your search parameters.
Also, I don't use MySQL myself, but are you sure about those single quotes around your table/column names, and does "&&" work like "AND" in MySQL? Does this SQL work if you run it via the MySQL SQL shell? If not, it won't work in Java either.
Do you really need to do "SELECT * ..." to read everything from your login table e.g. don't you think fetching the password into your Java code might be a security risk?
So yes, there are other things you need to do: You need to read up on how to use bind variables with JDBC to prevent SQL injection, always check your SQL via your database's SQL shell, and you need to think about what you are really trying to do with your SQL instead of just blindly fetching data that should probably be kept securely in your database.