Tim Moores wrote:At a quick glance, it seems that this code shouldn't even compile. The if/else in lines 70/71 is unbalanced - should there be braces around the two statements after the if condition, and also the ones in line 71?
Tim Moores wrote:I would also recommend not to override the service method. One should be specific about which HTTP methods are allowed, and in this case POST seems to be the only applicable one. So override the doPost method instead.
Michael Portman wrote:Nah I think ill just stick to what im currently using, thanks anyway. I could do a regex on the query before its passed in to prevent SQL injection. That would work wouldnt it?
Michael Portman wrote:What if I just escape all my strings then? Will that prevent an injection?
Bear Bibeault wrote:I would definitely put it on the MUST DO list prior to production deployment.
Dave Tolls wrote:However, with something like this, refactoring the proper way of doing it later rather than sooner will become much harder.
If you're already baulking at the idea of changing over to connection pools and prepared statements now, it's hardly going to be easier 6 months down the line.
Dave Tolls wrote:Since you're designing this yourself I would suggest going for the higher versions, unless you can think of a good reason not to.
The newer versions are likely to be more secure, if nothing else.
For setting up a standard tomcat connection pool there's this how-to for Tomcat 8, using DBCP.
There is a newer pool for Tomcat, however you'll find more examples for DBCP (the above link).
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |