Jump to content

View more

Image of the Day

Adding some finishing touches...
Follow us for more
#screenshotsaturday #indiedev... by #MakeGoodGames https://t.co/Otbwywbm3a
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.


Sign up now

Connecting to MySQL Database

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
2 replies to this topic

#1 Vincent_M   Members   

969
Like
0Likes
Like

Posted 21 May 2013 - 04:49 PM

I've connected my games to databases in the past using HTTP requests to PHP as the middle man using libcurl and the libmysql connector. I wonder though, which would be more secure: libcurl or directly via libmysql? A direct connection means to me, that queries I send could be compromised, and TS better POSTing ambiguous data via HTTP requests a d sending the data back in a tokenized or possibly binary format.

What would be the best?

#2 AllEightUp   Moderators   

5773
Like
0Likes
Like

Posted 21 May 2013 - 08:00 PM

Depending on your game, I tend to say no connection to the DB at all is best.  If this is on a web client type game, I would say the PHP middle man solution is the most secure because it allows the server side to validate things without relying on the client to be correct.  If, on the other hand, this is a standalone client in any language I suggest using a service oriented solution (though not directly REST style, you want a maintained session per client), the concept there is fairly simple, go take a look at Apache Thrift and the services generator.  Basically the client has to send well formed "messages" which the service translates into SQL to be used against the DB and then the results can be filtered and sent back to the client.

 

This avoids exposing the internal information about the DB to clients.  It avoids many cases of SQL injection or simply random SQL queries when the client is not supposed to be doing so.  And it allows better hardening of the server since you can add more code to double check at anytime without rolling out new clients.  A nice benefit, no need for any form of DB client interface at all, so slightly easier deployment.

 

Hope this gives you further idea's.



#3 Vincent_M   Members   

969
Like
0Likes
Like

Posted 21 May 2013 - 10:28 PM

Ok, I'll check out Apache Thrift. It looks interesting






Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.