HTTPObject vs TCPObject
by Robert Stewart · in Torque Game Engine · 10/25/2004 (7:42 am) · 4 replies
Well i was just wondering if HTTPObject is a better way to send data to Mysql through a php page, or if TCPObject would go straight to the Mysql DB, and if so wich way is better? thanks.
About the author
#2
10/25/2004 (8:34 am)
Well MySQL API has a big rumer that it is not as secure, at least for persistence data 216.116.32.49/index.php?sec=mg&mod=resource&page=view&qid=4085 thanks.
#3
What I did for our project is having no MySql access whatsoever from the clients.
Client use remote command to server and server will only access the DB, all DB code (db access, sql statements etc...) are sitting on the server. There I use ODBC to access MySql, we want to keep options open (another db) so MySql API was out of question.
The DB is then not open to outside world.
Use of PHP in my opinion is only adding trouble.
10/25/2004 (9:40 pm)
You have security problems anyway as long as you open you MySqlDB to outside. What I did for our project is having no MySql access whatsoever from the clients.
Client use remote command to server and server will only access the DB, all DB code (db access, sql statements etc...) are sitting on the server. There I use ODBC to access MySql, we want to keep options open (another db) so MySql API was out of question.
The DB is then not open to outside world.
Use of PHP in my opinion is only adding trouble.
#4
Then again I wrote an adbot-proof and thus-far-unhackable CMS in PHP, so I have an unfair advantage in terms of secure PHP coding. ;-)
The secure-coding part will be the trick. If you're exposing the DB to direct connections you're asking for someone to come along and inject commands into your DB, and if you're using a PHP layer in between you've got to make sure you're authenticating your clients and only passing thoroughly checked and cleaned SQL to the DB.
09/16/2008 (7:53 am)
Actually, PHP (or Perl if you prefer) is a smart solution if coded correctly. I'm building a Torque project that relays statistics to a central webserver, and will be using PHP as the data recipient and processing/validation layer in front of the MySQL DB. The PHP code will be validating and sanitising the everloving crap out of what the client sends, and there'll be some rather amusing trickery afoot in terms of security.Then again I wrote an adbot-proof and thus-far-unhackable CMS in PHP, so I have an unfair advantage in terms of secure PHP coding. ;-)
The secure-coding part will be the trick. If you're exposing the DB to direct connections you're asking for someone to come along and inject commands into your DB, and if you're using a PHP layer in between you've got to make sure you're authenticating your clients and only passing thoroughly checked and cleaned SQL to the DB.
Torque Owner Claude-Alain Fournier