Me and a friend is working on a multiplayer browser game.I'm in charge of coding the game in Java while my friend is in charge of coding the homepage and forums with php.

Lets say the java applet has a login screen in which the user types in his/her user info and will log in if the authorization is successful.

A lot of sources recommended me to use servlets to do this. I spent a lot of time studying servlets and came up with this:

User types user & pass in java applet and presses enterUsername and encrypted pass goes to servlet while applet listens for responseServlet compares username and pass with data in databaseIf matches, servlet retrieves user info (level, xp, skills) from database and sends it back to the appletapplet receives info and do whatever

Unfortunately, since my friend is using php and I require java, there appears to be a conflict. Only way to run java servlets is if I have java/tomcat hosting. I tested this with appfog and cloudbees however it seems that php cant run in tomcat.

So this makes it seem like I have to choose between my friend using jsp(not an option) or I'll have to find an alternative method.

Does anyone have any other methods they would recommend or a solution to the above problem?

I don't see why you can't implement this using an applet and php. As long as your php is sending back meaningful responses (xml is a reasonable format for this) in response to meaningful HTTP requests, the fact that the client and server are using different technologies is irrelevant.

I've implemented a service for saving high scores that does exactly this. The backend is in PHP (since that's what my host provides) and so far the only client applications are java applets.http://www.stimware.com/projects/game-service

Thank you so much. I had a feeling we could use php but I had trouble finding decent php - java tutorials online. I started testing with php and it seems great.

I've looked on security issues with applet and it being "hackable" (still dont fully understand the processs), but in the link that you've provided, how can we avoid the security issues?

If I'm going to guess the process of "hacking" it, it will be this(correct me if I'm wrong):1. I think that people can download the java applet and read the codes.2. They'll learn what the url to the php file is and what parameter that it takes. 3. Make a script (whether it's a php script or something else) that send POST/GET data to the php file with his own score.

If I'm correct with above, than how can we avoid this situation? I'm having difficult thinking of a solution where high scores get sent from the applet to a php file without specifying the php file url and the parameters.

I hadn't bothered addressing that in my implementation yet, as it's mainly a proof of concept but there appears to be quite a few ways of going about it. None of them that I could come up with are completely hack proof, only more and more difficult to get around.

You could have some sort of complicated handshake between the client and server, eg. the server sends back a random number "challenge" and the client has to use an algorithm to generate a response that the server validates. Once you've established the session like this, communication continues as normal. It won't stop a determined hacker from reverse engineering the code though, but at least it requires some effort.

A more effective solution I've found is to just make crappy games that nobody wants play. So far, no hacks! But it's an interesting problem and one that I'll probably look into more for my next game.

You could have some sort of complicated handshake between the client and server, eg. the server sends back a random number "challenge" and the client has to use an algorithm to generate a response that the server validates. Once you've established the session like this, communication continues as normal. It won't stop a determined hacker from reverse engineering the code though, but at least it requires some effort.

You might as well just use SSL, which is this handshake taken to its logical conclusion. If you think that would be too easy for hackers to get around, then the lesson you have to take away is that other clever tricks aren't going to work either. You don't need to hack the secure tunnel, just the message being sent through it. You think those people with scores of 99,999,999 on XBox Live leaderboards got that score legitimately? And that's on one of the toughest platforms to hack in the first place. The more of a challenge you make cheating, the more determined you'll make cheaters who otherwise wouldn't care.

I don't think the complicated handshake method should be used because it doesn't prevent any hackers, just gives the hackers much more work to do.

I looked online and it seems that people are saying that it isn't possible. But then how does games like runescape prevent this?

Is it possible to make the php recognize the applet or only accept request from the same host?

Finally, does Applet to Servlet communication have the same issue? 'Cause It seems that the issues will be the same but perhaps there's something different about servlets than php that allows to close this security gap.

You could make it recognize requests from the same host only, then this will rule out people other than yourself actually playing the game.

Making it only recognize requests from an applet will be impossible - whatever mechanism you implement to do that will be subject to the same kind of impersonation attacks as your main protocol.

A servlet will not give you any additional security as you will most likely still be communicating via HTTP. I guess you could serialize java objects and send them over the wire, but there's nothing stopping a hacker from reverse engineering your code to make their own objects. Being java, this is a fairly simple thing to do.

As sproingie suggested, you could just use SSL. This will prevent people from sniffing the packets the figure out how to hack your protocol, but they can still reverse engineer your code.

So the next question might be how to stop people from reverse engineering your code. Since it's java we're talking about, it's pretty straight forward to decompile. You could implement the client end of your communication using a native library which will slow them down a bit, and rule out hackers who aren't familiar with machine code. It's still just one more breakable barrier though, and could present problems deploying with your applet.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org