Game Development Community

TGE and FTP Uploading.

by David Byrge · in Torque Game Engine · 08/02/2007 (4:03 pm) · 3 replies

I have a button on my mainmenugui.gui that creates an xml file for stored usernames and passwords. I am wanting the file stored on the server side instead of the client side. I currently have the ../example folder shared as a virtual ftp site. So, I would like the file to be able to write the file to ftp://xxx.xxx.x.xxx/starter.fps/data/users//logindata.xml

I was told that stock tge doesn't support ftp but has anyone done it successfully? Any thoughts?
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner Andy Rollins
ZDay Game
#1
08/03/2007 (9:54 am)
You can investigate the HTTPObject, TCPObject objects and their use to send data or perhaps call a command line ftp executeable via a .bat file (assuming your on windows), I would warn against ftp however as it is in no way secure. Just to give you an idea your ftp site should be password protected but therein lies a problem in that you must then code/store the username and password somewhere in your game client which people will try and reverse engineer, once they have the password they can then effectively upload whatever file they like (for example overwriting another users logindata.xml with a version of their own which they know the password for effectively stealing accounts. As soon as the password gets hacked you'd then have to change it but then you've got to consider how do you send a patch to every single person that has a copy of your game (and how long it lasts before it's cracked again).

Secondly FTP traffic is not encrypted so any data transmitted could be stolen, again think users and passwords.. you could setup an sFtp service but that's another matter. You only have to look at games like Diablo 2 and World of Warcraft to see the lengths people will go to packet sniffing and writing bots to play the game for them

Rather than looking at an FTP way of transferring the file could you not use a CommandtoServer call and pass the username and password as params to that, then the server can write an XML file directly itself or personally I would store in a database that ideally is NOT accessible via the web (any point of contact with the web is a potential point of weakness).

Torque Owner David Byrge
#2
08/03/2007 (12:11 pm)
Very good information. Really has opened my eyes to a lot of things. Nothing is safe I guess, but the less vulnerable the better. I like the commandtoserver call idea. My trouble isn't necassarily getting the file written as much as it is allowing them to access the file later. The xml file and location is not known or seen by anyone until it is called up in the login process. The login code is what the client would have access to. Back to the drawing board. Thanks for that important info.

Torque Owner Andy Rollins
ZDay Game
#3
08/03/2007 (4:02 pm)
You could try a process like:

1. client connects to the server (as torque does by default)
2. User enters user & password on client
3. client encrypts password
4. client calls CommandtoServer for say serverCmdValidateUser passing the user and encrypted password.
5. server validates the user and password against xml, data files or a database.
6. server calls a commandtoClient for example clientCmdValidateResponse passing back whether we were successful or not.
7. if the login fails then the server drops the connection.