Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Java game linking to a perl script

by kiat (Vicar)
on Jul 14, 2005 at 13:18 UTC ( [id://474862]=perlquestion: print w/replies, xml ) Need Help??

kiat has asked for the wisdom of the Perl Monks concerning the following question:

Hey,

I've a java applet game. When a player completes a level, I need the applet program to call a perl script to update that information. Something like:

if (solved) { try { getAppletContext().showDocument (new URL(getCodeBase()+"index.pl?node=puzzle&solved=ab6eweyg")," +_top"); } catch (Exception ex) {} } }
But I suspect it might be possible to type the solved code directly into the url:

http://somesite/index.pl?node=puzzle&solved=ab6eweyg

Assuming the code "ab6eweyg" is stored in the html file that contains the applet.

Could someone suggest e a better solution?

Thanks in anticipation :)

Update

Still reading the comments. Thank you so much for taking the time to give enlightenment.

Replies are listed 'Best First'.
Re: Java game linking to a perl script
by halley (Prior) on Jul 14, 2005 at 14:05 UTC
    Well, my first choice would be for Java to do the work of saving the results on the server before jumping. It's nothing to do with what language each component is, it's just that it seems to me to be the best "responsible party." Encode a similar call to fetch a certain page but don't actually show the results (or the URL) to the user. Then you can jump to a new vanilla URL which shows the results.

    Barring that, learn how Java can POST the solved url information rather than GET the solved url information. The POST method hides the values they're sending, while the GET method encodes them into the URL where anyone can see or muck. I'm guessing Java has a way to do that, too. Methods GET and POST in HTML forms - what's the difference?

    Barring that, you should encode the URL parameters in such a way that the user can't recognize or muck them. That might mean that your Java and your perl need to share a key.

    If you're really trying to avoid all chance of snooping, you'd use a public key encryption scheme, whereby the Java applet only knows a public key and the perl script can read the encoded form in private key. Of course, since Java is a bytecode, easily decompiled language...

    --
    [ e d @ h a l l e y . c c ]

      To add one more option, you may want to take a look at Sleep, which is a Perl-ish scripting language for Java. It is easy enough to embed (since that was what it is meant for), has the ability to do what you want hidden from the user, and is seperate from the Java source itself, so you could update it seperately from the java. Just to add to the Pile of Ideas (пoй)
        What would using an embedable language gain that loading the various values, answer keys, questions etc.. that can't be done using something like XML, or just key-value pairs?

        Btw, I prefer Velocity. Yes, it's a template language, but you can write programs in it. Albeit very simple ones that can't do much, "harm."

        ----
        Give me strength for today.. I will not talk it away..
        Just for a moment.. It will burn through the clouds.. and shine down on me.

        Oh the joy of sleep, during which $self, $world, @problems and $pain are all undef.
      Thanks, halley!

      Ah, java can post the solved url?

      Will go find out more on that.

Re: Java game linking to a perl script
by ikegami (Patriarch) on Jul 14, 2005 at 16:16 UTC

    halley's answer is oriented towards protecting your data in transit. sporty talks about authentication. However, I believe you are asking how to prevent people from winning by peeking at the source instead of actually playing the game.

    The suggestion to use POST is good (since the request has side effects on the server), but it doesn't help the problem at hand at all.

    Public key encryption might be useful, but it doesn't help the problem at hand, since the hacker can get the public key just as easily as you can get the win code.

    You're faced the with the same problem faced by every maker of networked game which tracks stats/wins. And frankly, there's no good answer. The best answers are custom-made for the game they are meant to protect, and they often rely heavily on obfuscation and weak secrets.

    1) Run the game on the server. The applet would serve as a GUI, nothing more. If the game is run on the server, it can validate every move, and it would decide whether the player won, not the applet. This is quite secure, but possibly very expensive in terms of server resources.

    2) Add sanity checks in the clients. If there are multiple people playing the same puzzle at once, you can use the strategy StarCraft uses. Each player in the game verifies the moves of every other player. If a player performs illegal moves, the game is scrapped. Actaully, that's just the basic idea, because you don't want a player to cause the game to be scrapped when he's about to lose. It also doesn't protect from passive cheats such as map hacks. In fact, since verifying every clients' moves requires knowing the complete state of the game, there is "unlimited" information for passive cheats to use.

    3) Add sanity checks in the server. For example, if the game cannot be solved in under 30 minutes, reject any code received in less than 25 minutes from the start of the game. This could be implemented as follows:

    This isn't a foolproof solution -- this is a weak secret -- but it will be hard to figure out if you hide the fact that the game must run a minimum amount of time for a win to count.

    4) Have the server validate the win. Depending on the game, it might be possible to send the steps used to win the game to the server, which could quickly replay the game. The user would have had to play the game to know the steps.

    None of the above prevents a hacker from improving his best time by using a replay attack to improve his best time.

    Combine obfuscation, sanity checks and server-side validation for best results.

      Thanks, ikegami!

      This is what I've in mind for the solution:

      When the applet game is solved, the java code will get a unique code from a hidden file residing in the server (in a directory above public_html). It'll then call the perl script with that code to do the updating.

      The perl script will get the code from the same file and do the matching. If it's matched, the necessary database upgrading will be done and then it'll write a new unique code to the hidden file.

      Something like that. Not sure whether it makes sense...

Re: Java game linking to a perl script
by exussum0 (Vicar) on Jul 14, 2005 at 16:00 UTC
    Something more secure, eh? Have your applet register w/ the server using a random number, something 1 out of very large. The server would generate a unique key that when presented, will show the answer only to the person that presents the same large number and unique key.

    The large number represents a who-am-i. You can use IPs, but you then have to worry about people who nat, or are on load balancers. Acts like a cookie to present to the server.

    They key would act much like your key. Something that's one time use, and only hackable if you hack the client. Nothing that would be easily guessable by checking urls. (Imagine if your key=answer).

    Update: Collisions should be rare if you append say, the ip to the random number.

    ----
    Give me strength for today.. I will not talk it away..
    Just for a moment.. It will burn through the clouds.. and shine down on me.

Re: Java game linking to a perl script
by MonkPaul (Friar) on Jul 15, 2005 at 14:21 UTC
    I just thought, since your java program is in java (obviously), you can save the data into a vector or other data structure.

    You can then pass this to another class say "loadingClass" that will show a loading applet whilst you process the information, i.e saving that data or whatever you want to do.

    After this has completed you can then reload you applet or go to the next one in the series.

    This way you will have no need to mess with perl and try to embed things etc. Plus you will gain some nice loading page applet that looks all pretty and colourful.

    Any help......probably not. Let me know. Cheers,
    MonkPaul

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://474862]
Front-paged by broquaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2024-03-19 08:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found