This is my last reply to this meaningless off-topic, what you say you write is exactly what I wrote. I gave advice for people that havent yet met the problems related to unprotected server code, to use this carefully and to watch what they send from a client app, to only trust their server code(on a dedicated machine).
And what did you do? Call me an idiot...Where's the 'pointing out' how dangerous this is? I dont think its dangerous to protect your app...

Anyway, I'm trying to help people that might use this plugin from making mistakes like everyone else, I dont wish to take the topic and the contribution to the trash. I'm not going to write off-topic anymore here.

Thanks to all who understand my motives in contributing with this plugin!
(^.^).

Unfortunately there are those who are against the use, and not given due weight to this contribution.
Currently I have only worked for their own use the MYSQL plugin, since I'm using in my application (Client Server x). However Descontinuei the contribution, to avoid problems with those who are against!


If there is someone really need to use send me PM I'll be contributing.

For those who would like to use a database like mysql but only in applications CUSTOMER, I have also worked in plugin for sqlite3.

http://www.sqlite.org/copyright.html

Okay, here is why this is wrong on more levels than there are ranks in Call of Duty, and why I have no problem to drag this contribution into the trash. I won't say fuck, I won't call anyone an idiot and I'm going to explain it in detail. It's grouped in multiple categories, so just read on before flaming me.

Connecting the Client to MySQL
- The very first problem here is that MySQL is under the GPL license. GPL is a viral license, meaning that anything that uses anything with the GPL license, must be under the GPL or a GPL conform license. Furthermore, GPL requires you to open source your source code. If someone asks for your source code, you have to give it to them, free of charge. This also goes when you use a dynamically linked library, like, for example: mysql.dll. If you link against it, your source code must be under the GPL, if it isn't, you can be sued. Like, really, in a court.

- The next thing is that MySQL isn't made for that. Users, and thus the client, are inherently not trustable. Everything that you receive from them should be treated as malicious, because you lose all control over the input and the user can easily tamper it. MySQL does exactly what you tell it to do, there is very little you can do in terms of restrictions and access control, and the things you can do are not enough. If you give the user the means to connect to your MySQL server, you are basically screwed, because everyone can then access your MySQL server and run arbitrary commands against it.

-- This doesn't count just for MySQL, it's a general rule of thumb. Whatever you ship to the user, you have to assume to be compromised. You can't ship secrets to the user and expect them to remain secret, if you don't want the user to access something, don't give it to them. If you don't want your game to be cracked, don't ship it. One way or another, your game has to decrypt its resources and make its connection, and that is done on the clients side, on their machines, which they have full control over. Ship it to the client and its compromised by design.

- They way to handle these things is by having a layer between your database and your client, which only you have control over. The client can submit requests to this layer, and get the appropriate responses, but they don't have any other control over the layer. The layer then sanitizes the input from the user. Remember, the client is going to send you ill formed data, if you just blindly accept everything and forward it to the database, they can again do whatever they want. The layer should provide a well formed API that your program accesses, and it should make sure that the user can't break out of the layer and gain additional control.

- The layer does the input sanitation. You can't trust the user, so performing it there just makes you write code twice that you then have to maintain. You can't assume that your client sends sane input just because your software, that, again, runs on the clients machine, is still sane when it reaches your server. Even worse, it gives attackers the possibility to gain knowledge about attack vectors. If you are trying to suppress certain things, then it's valid to assume that this is a potential attack vector into your server.

- The server is responsible for maintaining its data. Not the client. The server maintains the data, and has to prepare for changing clients. Once you ship your software, its in the wild and can't be changed anymore. If you want to change the server or how its represents the data... Well, good luck with that when the client maintains the data on the server. But if you use an intermediate layer that you always have control over, you can change your server, as long as the client facing side of the layer stays the same. Even better, with future updates, you can update your intermediate layer to support both versions, even if the new version has additional features that can't be provided to the previous one.

MySQL for your dedicated server:
- The licensing issue remains the same

- MySQL runs as a server. It's not a library that runs in the context of your application, it runs as an extra daemon, that you usually talk to via a socket. You now have two problems: First of all, you need to ship MySQL with your software (licensing), and spin it up every time your game starts (and make sure it doesn't clash with a MySQL that your user might run). On top of that, you have to use sockets. Sockets use IPC, the two processes aren't running in the address space, so the Operating System has to make expensive copy operations just so you can communicate with your database. IPC is expensive. Period. That's why we don't use microkernels.

- MySQL isn't made for that. Sure, you can run your 64 placer dedicated server with it, but it's like breaking doors open with a tank just because you found a tank in your garage. Simply put, MySQL is the wrong tool for this, it is made to be a long running daemon in the background that can store a lot of data consistently and persistently on a server. You don't spin up a long running daemon on your clients machine.

So, what then?
That depends on what you want to achieve. If you want persistence across all users, use a MySQL server with an intermediate layer that clients connect to. If you just need a database to store things for your dedicated server, use sqlite3 which is lightweight and runs in the same address space as your program (and doesn't have licensing issues, is fast, has a incredible amount of unit tests and is well proven, well tested software). If you just want to store some things for the lifetime of your server, just keep them in RAM in an appropriate data structure.

If you use Gamestudio as your non dedicated Server software: Don't. Even Conitec wrote their Sex MMORPG servers in C and for Linux. Why? Because a) Windows Servers are expensive, b) Gamestudio scales badly and c) Lite-C isn't made to server thousands of clients but to be a Client.

I hope this made things a bit more clear, and also why I disagree with you, EpisloN, about the fact that you gave helpful advice to secure software. If you have any questions, feel free to ask.

See? A helpful reply...

Its not so hard to speak like a human. Btw , congratz on the extensive post, now you gave a very meaningfull reply wich I enjoyed reading.

PS.: When I wrote MySQL I ment any SQL server, but I'm just used to refer to all SQL servers as MySQL. Thats my bad, I didnt explain myself.

SQLITE3 FOR LITEC UPDATE:
Topic:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=421684#Post421684

Projetc:
https://sourceforge.net/projects/sqlite3cworkitv10/files/3DGD/

Download Release:
https://sourceforge.net/projects/sqlite3cworkitv10/files/latest/download?source=files

Hey Sid, thanks for your post. I completely agree with you, but have a question regarding the GPL virality.



Are you sure code linking against mysql.dll would need to be GPL too? Wouldn't this mean web applications (like PHP scripts using mysqli or Ruby apps utilizing mysql2) were also affected? What did I miss here?
Thank you

Yes. That's the major point of the GPL. If you directly link against, or incorporate GPL'd code, your work must be under the GPL or a GPL conform license (as opposed to, for example, the 3 or 4 clause BSD license which requires you to only attribute the work).
There is a special version of the GPL, called LGPL, which allows you to link against binaries which are under the license without having to open up your source code (for example the glibc is under this license, so just because you use the standard C library on Linux doesn't mean your source code has to be GPL).

But, here is the point: You have to link against it. You can use other forms of communication, for example IPC or the programs ABI, to communicate with the program without having your applications become infected by the GPL. This is crucial, for example, it allows you to ship a disassembler like Hopper which can work with GDB, but doesn't have to be open source. Another example: GCC itself. Just because you compile some source with the GCC, or write an IDE which uses GCC doesn't mean your source code must be GPL. If the GPL'd program/library isn't part of your program (and it becomes if you link against it), you are good to go.

And that's why your PHP scripts are fine. PHP is under the GPL (and must be, because it links against a huge amount of GPL software), but your scripts don't have to be. They don't link against mysql, openssl or anything, they are just interpreted by PHP which does everything, and which in return is licenses under the GPL. Okay, now I hear you: But Ruby is under the 2-clause BSD, you don't know jackshit. Yes, Ruby is, but Ruby isn't PHP. It's not an umbrella over every open source software that didn't run away fast enough, the interpreter doesn't link against any GPL software. The mysql Gem however does, and guess what license it is under? GPL, of course.


Oh, and speaking of MySQL, if you want to use it, but hate the GPL: You can dual license GPL software. I mean, it's yours, you can change the license whenever the fuck you feel like it, with the exception that you can't change it in retrospect. Oracle does that, if you want, you can go to them and ask for a non GPL licensed MySQL. They will give you their bank details and you wire them some money (no, actually, if you smell like enough money, they will send an Oracle rep to you who gives you a five hour long power point presentation about why YOU need Oracle db and their enterprise support)