Dave Tolls wrote:Take us through this a step at a time.
Where is the project that you are compiling?
How are you compiling it (command line etc)?
Where does the compiled class file end up?
What steps do you take to deploy this and restart the server?
That's just a start.
Also, is there any old copy of the original java file around?
If so, where?
Paul Clapham wrote:What is it that makes you think the compiler is somehow looking at the nonexistent code? Have you eliminated other possibilities, such as that you haven't successfully deployed the result of the compilation?
Paul Clapham wrote:
Michael Portman wrote:Preventing a SQL attack is the least of my worries while my site isnt live yet. Getting the user login system working is my main priority atm.
"I know this is wrong, but I'll fix it later."
Problem is, there's always more important things to do later -- until the security breach happens. Really, just use a PreparedStatement. It's not like it's any harder than using a Statement, in fact it's easier because you don't have to mess with getting the single-quotes and double-quotes right.
Paul Clapham wrote:
Michael Portman wrote:I'm little confused over these preparedStatements are talking about. Couldn't I just escape all of my string which go into DB with replaceAll()/replace(), or maybe even use Regex?
Here's the tutorial: Using Prepared Statements
As for doing something yourself to avoid SQL injection attacks: if you were a better programmer and experienced in the art of SQL injection attacks, that might be a possibility. But why go to all that work when you can just use a PreparedStatement?
(And as for escaping things, that's one of the tasks of PreparedStatement. You haven't written the code to escape quotes in the user name, anyway. But that code would be dependent on what database you were using, which is another reason to let PreparedStatement do it for you.)
Paul Clapham wrote:
Michael Portman wrote:Can everybody agree this is the correct way of doing things? Cheers.
Not for a real application that's going into production for real users, no. If you're just trying to learn Java web apps then I guess it's okay, but for a real application you should use a PreparedStatement to access the database; building SQL using string concatenations allows SQL injection attacks to corrupt or damage the database. At least you're not storing plain-text passwords in the database, gotta give you credit for that.
Here's another quibble:
When you see Java code like "if (booleanValue) variable = true; else variable = false;" you can replace that code by "variable = booleanValue".
Dave Tolls wrote:No.
You user the query I gave you above.
You only want to find a user who matches both the username and password given.
So the query needs to have a WHERE clause with that AND in it.
That's how all login methods work.
Dave Tolls wrote:OK, looking at that Login class.
The use of that MySQL class seems to imply you are not using a connection pool, which is generally not a good idea with a webapp. Depending on how many concurrent users you are likely to have you may find yourself running out of connections.
I'm going to treat the Login class like a DAO (Data Access Object), since that seems to be what it is.
So, when interacting with the database using JDBC in a webapp you'll generally see the following structure in a method:
You need those try-with-resources blocks to ensure the resources (the result set, statement and connection) are closed, otherwise you are going to run out.
The getConnection() call simply hides whatever mechanism you are using to get a connection...as I say above, it should be using a connection pool.
So that's the basic structure you will have in your db interaction method(s).
For the Login, it's a single query:
If that returns a row then the user is valid, otherwise it is not.
So, I would expect a single method on your Login class, called getUser(String name, String password), which returns a User containing whatever data you need.
Hope that's not too much of an overload!