Anyone here using mySQL inside a VST/AAX/AU plugin?

[Fender19]

I would like to incorporate mySQL code inside my plugins to check license codes against a mySQL database when the plugin loads (is "constructed") but my attempts so far have failed.

I have all the proper mySQL headers and libraries linked in and the plugin builds without error. However, as soon as I add even one mysql function to the code (like getting started with "mysql_init(NULL)") it breaks the plugin interface and the plugin refuses to load in any DAW.

I'm not even trying to connect yet, just trying to initialize mySQL and it's breaking the plugin.

Just curious if anyone else here uses mySQL inside a plugin and, if so, what is the "trick"?

(BTW - what makes this difficult to fault isolate is that mySQL won't run, or even build, in debug mode)

[BertKoor]

Bad idea. My user id and license code is

Code: Select all

' OR 1=1; DROP TABLE users; --

No one in their right mind these days allows clients to open a database connection directly.

Do a REST call over HTTPS to a web service instead. In a separate thread. It's not only far more secure, it separates business logic (is the client a paying one) from the actual implementation (having records in a database) which might change at your will, even on old clients calling it.

[gryzor]

Dangerous idea... it could be pretty easy to dump the database and maybe gain acces to your server.

[Fender19]

I found the problem - 3 mysql dll files are required alongside the app in the delivered product. I don't understand why the necessary mysql code can't be built into the executable, but that's problem #1 as I want a "self contained" plugin file.

And now that I solved that issue...

No one in their right mind these days allows clients to open a database connection directly.

I agree 100%. I'm just getting started trying to figure out how to go about this. Embedding a password to the database in the plugin code is NOT the right way!!

Do a REST call over HTTPS to a web service instead. In a separate thread. It's not only far more secure, it separates business logic (is the client a paying one) from the actual implementation (having records in a database) which might change at your will, even on old clients calling it.

I will look into what you said here. Thank you for the input.

[mystran]

No one in their right mind these days allows clients to open a database connection directly.

I agree 100%. I'm just getting started trying to figure out how to go about this. Embedding a password to the database in the plugin code is NOT the right way!!

Wait.. that's not where your problems start. Exposing an SQL database to the internet in the first place is already a terrible idea.

Do a REST call over HTTPS to a web service instead. In a separate thread. It's not only far more secure, it separates business logic (is the client a paying one) from the actual implementation (having records in a database) which might change at your will, even on old clients calling it.

I will look into what you said here. Thank you for the input.

REST sounds scarier than it is. You have a webserver serving a dynamic "webpage" the contents (or even status code; one could reasonably return 403 if a license check fails) of which depends on the request parameters. Only the script implementing the URL handler needs access to database. Your plugin also doesn't need to know how the validation is done on the server side. All it needs to know is how to send a standard HTTPS request and check the results. This means that you are free to change the implementation on the server side without having to update the plugins and reverse engineering the plugin doesn't give any insight into what is or isn't done.

[Fender19]

REST sounds scarier than it is. You have a webserver serving a dynamic "webpage" the contents (or even status code; one could reasonably return 403 if a license check fails) of which depends on the request parameters. Only the script implementing the URL handler needs access to database. Your plugin also doesn't need to know how the validation is done on the server side. All it needs to know is how to send a standard HTTPS request and check the results. This means that you are free to change the implementation on the server side without having to update the plugins and reverse engineering the plugin doesn't give any insight into what is or isn't done.

My new plan is to use CURL to send an HTTP POST request from the plugin to a PHP file on my server and then access the SQL database from the PHP code.

Is that about right? (I don't know what "REST" is but I assume it's a similar HTTP request?)

[BertKoor]

We use REST as an umbrella term these days where we could say http call as well. REST just has some extra (and very easy) semantics. It is THE standard these days for communicating with a web service.
https://en.m.wikipedia.org/wiki/REST

Compare with less actractive alternatives:
https://en.m.wikipedia.org/wiki/SOAP
https://en.m.wikipedia.org/wiki/Common_ ... chitecture

C examples: https://stackoverflow.com/questions/220 ... e-response

C++: https://stackoverflow.com/questions/101 ... est-with-c

Or google "c++ example http call" for more

You said curl. Do you mean LibCurl, or as I understood calling curl.exe ?

[Fender19]

You said curl. Do you mean LibCurl... ?

Yes. But I will take a look at the links you posted here. Thank you!

[BertKoor]

Implementation detail: if you really care, then do check certificates with whatever you communicate with.
For a hacker it's easy to let your plugin communicate with his own thing that always responds with 200-OK.
https://en.wikipedia.org/wiki/Transport_Layer_Security

[mystran]

Implementation detail: if you really care, then do check certificates with whatever you communicate with.
For a hacker it's easy to let your plugin communicate with his own thing that always responds with 200-OK.

Well, yeah. You need some way to validate that you're actually getting the response from the desired server. HTTPS certificates is one option, though make sure these can't be faked with locally trusted CAs issuing fake certs. Sending a random code (to prevent replay attacks) as part of the request that the server signs and the plugin checks against public key stored in the plugin is another option and should work even over HTTP, though vulnerable to tampering with the public key stored in the plugin (but dealing with tampering of the plugin binary itself is kinda different problem).

Also when using some standard library like libCurl or whatever, it might be relatively easy for a hacker to figure out that this is what is going on and just stub the relevant calls with alternatives that return "everything ok" .. so I'd personally probably add some checking mechanism to the response body anyway.

[Fender19]

...it might be relatively easy for a hacker to figure out that this is what is going on and just stub the relevant calls with alternatives that return "everything ok"...

I am trying add some protection without turning the protection itself into a career project. I don't know of any software that hasn't been hacked by someone somewhere (even iLok and dongle) so trying to make it "hackproof" is futile, IMO.

I'm going to do what I can but prefer to spend the bulk of my time working on the product itself. I know who's purchased it and if someone not on that list contacts me for help then I have 'em identified. What's passed around on hacked software websites is usually filled with viruses and other garbage so that's their own trap. Worrying about it is wasted energy, IMO.

Thanks, everyone, for your help and input here. BTW, I am using HTTPS.