On Aug 12, 3:02*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AeonOfTime wrote:
Let's assume a web application (in this case a browser-based game)
with a custom HTTP server built on PHP, and a client also built on
PHP. The client uses the server to access and change data. Even if the
client server communication is not directly visible to the user (who
logs into the client), the fact that the server is publicly accessible
(a port sniffer would be enough to find it) means the communication
has to be secured.
First of all, clients are not normally built on PHP. *Client systems
generally don't have PHP installed. *Additionally, if they do use PHP as
a client app, they won't be able to use the browser for a GUI. *They'll
either be restricted to CLI or you'll have to have them install a PHP
GUI, also.
Hi jerry, I may have used the wrong terminology there. In my case, the
client is the PHP script that runs on my own server, and which
generates web pages via which users play the game. It is not a client
in the traditional sense that it runs on the user's system. Ideally I
will have one physical machine for the server that exists simply as a
central management source for game data, and several other physical
machines for rendering the game with load balancing.
Thus the only thing a user needs is a browser, and the communication
between client and server happens only between my own personal
scripts. Sorry for the confusion.
>
How would you go about securing the data exchanges?
Secure data transfer is typically performed with SSL. *But my question
is - what is being transferred that you need SSL? *Is there anything
potentially harmful if leaked, like credit card numbers or other
personal data? *And even if someone does intercept a game move
(unlikely, but possible), what real harm will it do?
The harm lies in the fact that I plan on making the game code open
source in the future, giving players full insight in how the system
works. There is no critical data being exchanged per se, but I do not
want any data to be leaked either. I don't think I will go for an SSL
connection though, that would be overkill and slow down the
communication somewhat. I think a unique client token will be enough -
that way even if you were able to intercept something you could not do
anything with it.
>
Sounds like the wrong approach to me. *If you really need a client side
app, you should be using a Java applet, not PHP. *Java is installed on
many (most?) systems, it has a GUI, and can easily use it's own
communications mechanism between the client and server.
Yes, java or even flash could have been a choice for a GUI, but I
settled for plain old HTML for now with enhanced functionalities in
Flash and AJAX, it is sufficient for what I have in mind.
Thanks for the input.