Keeping the internal workings of an EA on an external server - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Haha ok maybe he is, he does seem very smart with that stuff. So I guess the conclusion I have come to then would be to compile most logic into a dll which I'm sure if I get stuck I could find most that information online for how a dll and ex4 talk to each other?
Study the dll example that comes with MT4, the basics are there. More advanced topics are in the forum. Search'em.
The last thing then is still in which manner the dll will authenticate the user. Should I make a MySQL database which stores keys and when a user turns on their EA the key is checked against the database and logs the IP address to make sure there isn't more then one person using the EA at the same time or does someone have a better/simpler authentication method that is less likely to result in false user lockouts? To me the IP logging doesn't seem very accurate.
Personally I would just have the user's account details hard-coded in the dll (obfuscated in some way) and verified when the EA is used. It should be easier to code and does not require a server. If done properly it's going to be just as effective.
The last thing then is still in which manner the dll will authenticate the user. Should I make a MySQL database which stores keys and when a user turns on their EA the key is checked against the database and logs the IP address [...]
If you're going to do validation over the web against a MySQL database, you might as well do the code obfuscation using the web server route rather than the DLL route.
Most EAs lock themselves against broker account number rather than username and password. There are two reasons for this: (a) it side-steps the issues you've identified in people sharing usernames, and (b) it gives you the opportunity to charge the same person multiple times, in a way which is broadly correlated with their spending power and with the value of your system to them. (I.e. if person A has one account and person B has five accounts, then person B probably has more capital and your system is probably making more money for them than for person A.)
In case you've not come across this sort of thing before, the usual method is to collect a customer's account number and issue a corresponding code (which is some sort of algorithmic product of the account number). The user than has to enter this code as a parameter for the EA. When it starts up, the EA replicates the calculation which turns an account number into a licence code, and checks that the code derived from the user's account number matches the code they've entered as a parameter.
One particular problem is that you can't do this validation of the licence code in the EA itself. All someone would have to do is decompile the EA, and remove the bit which handles the licensing. Things potentially become quite complicated here depending on how paranoid you're feeling. Let's say that you do the validation by sending the account number and the user's licence parameter to a web server, which sends back a yes/no response. In its basic form this is vulnerable in two ways:
There are lots of very well known commercial EAs which are vulnerable to one or both of the above. (Same principles involved when using a DLL rather than a web server.)
[...] even though theoretically any EA can just get the account number and send it to the author anyway.
Yup. And, with most brokers, it's very easy to guess valid live account numbers anyway.
decidence wrote >>
[...] I suppose I can have each user supply their account number and then authorize that
If you're going down the web-based route, they could fill in their account number online and have an automated web page generate a licence code.
The latent issue which this then brings out is licence expiry. Multiplying the options yet further, there are basically two ways of handling this: (a) send the account number/licence to a web server, and have that check that the licence continues to be valid, or (b) build an expiry time into the licence code which is issued to a user, and periodically send new licence codes to everyone.
Ok jjc, I've read what you wrote three times now but I'm kind of confused with why I can't use the DLL to connect to a database and authorize the user's account number. My original thinking was I would have the user supply their account number and store that number in the database, then the DLL would have authorization code which would compare AccountNumber() against the database. If I am solving the "easy decompile" issue with using a DLL then I shouldn't be worried about a user replacing AccountNumber() with any account. Which leaves me wondering what you mean by not using a DLL at all if I choose to go this route.
I'm referring to this "If you're going to do validation over the web against a MySQL database, you might as well do the code obfuscation using the web server route rather than the DLL route."
Ok jjc, I've read what you wrote three times now but I'm kind of confused with why I can't use the DLL to connect to a database and authorize the user's account number.
A database on the desktop, or a database on a web server? If the database is on the user's desktop, then you've got big problems stopping people from hacking into it...
decidence wrote >>
[...] I'm referring to this "If you're going to do validation over the web against a MySQL database, you might as well do the code obfuscation using the web server route rather than the DLL route"
All I was trying to say is that it sounds like you currently have little or no experience of either DLL development or web development. If you are going to need to write some web code to handle licensing, then you might as well do everything on the web rather than having to get up to speed with both web development and DLLs. (Unless latency is a big deal in your strategies. If it is, then doing a round-trip to a web server in order to confirm potential signals might be a problem. But this isn't likely if your starting point is manual trading systems.)
I see. And I meant a database on a server not on the user's machine. I'd likely be more comfortable with learning the DLL route since I work in a C++ environment every day at work anyway and it should be a little more relevant. And I think connecting to a MySQL server and validating a key from a DLL should be a fairly amateur/intermediate level project?
Web development scares me! I rely on CMS tools to build websites.
As much as the technical aspects of this discussion are interesting (that's some good stuff, jjc), I really don't understand why u would go to all this trouble?
You are taking other people's ideas and turning it into an EA. It wasn't your idea in the first place, so what are u protecting? The internal workings of the EA are out there even before you wrote the first line of code...
I'd likely be more comfortable with learning the DLL route since I work in a C++ environment every day at work anyway
If you "work in a C++ environment", then it should be a very minor extra step. A DLL is just a block of C/C++ code meeting a very simple specification in terms of calling conventions and function exports.
And I think connecting to a MySQL server and validating a key from a DLL should be a fairly amateur/intermediate level project?
I'm not sure if you're describing the complexity of the DLL code as amateur/intermediate, or the complexity of some web server code to query a database. But the same is true of both. (It's possible that MySQL has some sort of web connector which avoids the need to write any web server code to query it. However, you'd need to be careful that you didn't expose your entire database to the world using such a thing, and you'd have trouble preventing man-in-the-middle attacks on your licensing.)
However, doing the signal validation on the server rather than in a DLL is also amateur/intermediate level. For example, let's say that you had a very basic system which trades a MACD cross, but only if the direction of the cross matches the MACD value on a higher timeframe for the same symbol. You could simply do the following:
Yea that last point you make "examines the MACD values and returns a simple yes/no response" is the part I have no idea about. Since some basic app's in college I have since had no experience with network programming. I'm a gameplay and user-interface programmer for a game development studio. I don't really work in making tools and small app's. But I do agree with you, ideally that would probably be my favorite way to do this although it may make my bandwidth provider hate me in the long term?
Gordon: The whole point is I'm not looking to make other people money for free. If someone has a great idea or a manual system that works really well automated and can't do it themselves they can either, learn how to program it, pay someone to develop it and retain the rights to the property (if the intention is to sell it then they would want all this extra work done anyway which is another reason for me to learn), or get someone to do it for free under the guise of not re-distributing it. I don't trust people not to re-distribute my free work. What am I getting out of doing this work for free? If someone provides a great system that works well then I can trade it myself and even moreso wouldn't want it being sold all over the internet.