need your feedback on running my querries server-side
Hello all.
I'm building a web applet that will administer a large database.
I've recently been informed that due to the nature of applets this will result in all SQL querries being run on the client-side, thus forcing me to allow outside access to my mysql database. I'm not too thrilled by that thought and was wondering if there's a way around it.
In my applet I have one class named dbOper.java that handles all the sql querries. Is it possible to store this part of the applet server-side and make the client applet interact with it?
Just to clarify in case I'm being too vague. Optimally I'd like the mysql connection string to connect to localhost. This would greatly increase security and would prevent a wise person from getting access to all my SQL methods and potentially doing whatever he wishes with my DB.
Thanks for any input you can give, I appreciate it very much.
[923 byte] By [
vesper8a] at [2007-10-3 4:11:30]
> Hello all.
>
> I'm building a web applet that will administer a
> large database.
Sounds like a bad idea to me...
> I've recently been informed that due to the nature of
> applets this will result in all SQL querries being
> run on the client-side, thus forcing me to allow
> outside access to my mysql database. I'm not too
> thrilled by that thought and was wondering if there's
> a way around it.
J2EE & Servlets. You could do Applet to Servlet communication and then the Servlet could store the data. I'd do that.
> In my applet I have one class named dbOper.java that
> handles all the sql querries. Is it possible to store
> this part of the applet server-side and make the
> client applet interact with it?
Again, bad idea if you ask me.
> Just to clarify in case I'm being too vague.
> Optimally I'd like the mysql connection string to
> connect to localhost. This would greatly increase
> security and would prevent a wise person from getting
> access to all my SQL methods and potentially doing
> whatever he wishes with my DB.
>
> Thanks for any input you can give, I appreciate it
> very much.
thank you for your input. You're not the first to tell me it's a bad idea... but Java happens to be the only language I'm comfortable with at the moment and the only one I could see myself building a project of this size on.
Also it's a small website and I don't particularly fear others trying to do malicious things to my DB. Still I would like to take what precautions I can. I've heard of servlets and they seem to be a good way to go.
I was also considering using one or more obsfucators and I also thought I could store my mysql connection values as binaries instead of plain strings and make my own small encryption/decryption method. With all that it should be pretty darn hard for anyone without a bachelor in computer science and a vivid imagination to mess with my code and my DB. At least.. that's what I think.
The best way would be to have the applet interact with server side code (like a servlet) as mentioned.
If you really insist on doing it in the applet do not waste time on obfuscation etc but do take the following steps.
1) Prompt for the username, password etc information in the applet each time.
2) frequently change your password
3) If at all possible use a secure connection (SSL) to your database.
4) Lock down your database to only accept connections from a particular client (by IP address).
thank you for your clarifications cotton.m, they are much appreciated.
Let me ask you this please. I'm going to go with the servlet method. Won't this effectively make all my interactivity with my sql database come from localhost, since the servlet will be on localhost and it will be acting as a bridge between my applet and my DB ?
my original idea was to somehow get my class with all the database access code to not be part of the applet. Since that's the class that contains ALL the sensitive information (sql querries, connection values). If that class was well out of reach of the DB users then my problem would be non-existant.. at least as far as security is concerned.
do I pretty much have it right concerning the servlet and what it can do for me?
also.. if you wouldn't mind.. do you have a good link explaining servlets by any chance?
and one last thing.. concerning obfuscators, they may not be the solution to adequatly hiding my sql querries and connection values.. but doesn't good obfuscation at least take care of the otherwise too easy reverse engineering that can be done on my other java classes? If I can make code stealers/snoopers jobs a little harder than that seems a good thing in my book.. no ?
thanks again!
> thank you for your clarifications cotton.m, they are
> much appreciated.
>
> Let me ask you this please. I'm going to go with the
> servlet method. Won't this effectively make all my
> interactivity with my sql database come from
> localhost, since the servlet will be on localhost and
> it will be acting as a bridge between my applet and
> my DB ?
Yes. More or less.
Localhost assumes that the web/application server and database server are in fact on the same physical machine and they might not be. But the idea remains the same.. yes it is acting like a bridge or proxy between the two (applet and DB).
> do I pretty much have it right concerning the servlet
> and what it can do for me?
>
Yes.
> also.. if you wouldn't mind.. do you have a good link
> explaining servlets by any chance?
Well here's were the waters get muddy...
A "servlet" in the context we are using here means code that executes in a web server that takes HTTP requests and outputs something back. The "something" back could be an HTML page, an image, some binary data whatever you want. Commonly used for this sort of purpose and what I would recommend here is some sort of XML.
In a nutshell when you have some server executing code that is interacted with by XML over HTTP we call that a webservice (so it is worth the time to look at how to implement this in a standard way) probably.
Now you'll notice I said code and not just Java. A servlet again in the context here does not mean Java neccessarily. You could use whatever tools at hand to produce the webservice XML on the server side. It could be Java. It could be ASP. It could be Perl. Whatever.
Personally the three times I have done things like this I haven't used Java yet on the server (twice in ASP and once in PHP).
At any rate there is a thing called a Servlet that means the Java way of implementing a Servlet as described above. It is Java code that is executed in the web/application server and produced output which is sent to your applet over HTTP.
Honestly I don't know what's the best route for you. Java Servlets IMO are not easy. If you know something else then I would lean towards doing that and you can come back to it later if you want to learn. Java Servlets are very powerful and good but they do have a steep learning curve IMO.
>
> and one last thing.. concerning obfuscators, they may
> not be the solution to adequatly hiding my sql
> querries and connection values.. but doesn't good
> obfuscation at least take care of the otherwise too
> easy reverse engineering that can be done on my other
> java classes? If I can make code stealers/snoopers
> jobs a little harder than that seems a good thing in
> my book.. no ?
>
> thanks again!
I think if you ask 10 different people about obfuscation you'll get 10 different answers. My personal take would be that yes they do make the stealing of your code more difficult however an obfuscation should NEVER be used as a security step to make your application more "secure".
