良いEAができた場合、身内で配布したい場合があります。しかし、知らない間に自分のEAが出回っていた場合、身内を疑いたくはないものです。
EA・インジケーターを第3者に渡すとき、何かしらの制限をかけておかないと、コピーされてしまう可能性があります。制限がないEAの場合、コピーされれば、知らぬ間にいろいろなところで使われてしまいます。
そこで、EAに制限をかける必要性がでてきますが、現在では様々な制限手法があります。 EAにつける制限にはいろいろありますが、それぞれ一長一短あり、 状況に応じて（技術レベルに応じて）使い分けられるといろいろと便利だと思います。
固定のパスワードで口座制限をかける
これも比較的安直で、ソースコードに適当にパスワードを書いて、それをパラメータで認証させる方法です。
お察しの通り、EAとパスワードがセットで流出すると何の意味もありません。
もう一捻りしたいところです。
extern string Password = "The password";
//...OnInitとかの記述
void OnTick()
{
if( Password != "The password" )
{
Comment("The password is wrong.");
return;
}
//...メインコード
}
コンパイル時に口座番号を書き 口座縛りする方法
これは比較的かんたんで、ソースコードに直接口座番号とFX業者を書き込んでおき、その組み合わせ以外のユーザーの場合は稼働しないようにプログラミングするだけです。
口座番号で縛ったり、特定のMT4業者でしか動かないようにしたり、デモ口座では稼働しないようにすることができます。
しかし、利用者ごとにソースコードを編集してコンパイルする必要があるため、２～３人の場合は良いですが、数十人に対して配布する場合は、かなり面倒です。また、口座番号が変わった場合には再度配布しなおす必要があります。
ヒューマンエラーも発生する要因になります。
まず、 ソースコードに直接 「この口座番号、この口座名のアカウントでしか動かしませんよ」という 記述をします。
void OnTick()
{
if( AccountNumber() != 1234567 || AccountName() != "Taro Yamada" )
{
Comment("This account is not allowed.");
return(0);
}
//いろいろトレードの記述 ↓
}
コンパイルすると、 その指定した口座以外では、何も動作しなくなります。
口座番号からパスワードを作って口座縛りをかける
口座番号から一意のパスワードを生成する方法です。Hash関数やsha256に近いことをします。
例えば口座番号が123456789だったとします。
その場合、(一桁目の数字)*4+(二桁目の数字)*3+(3桁目の数字)*2の答えである1*4+2*3+9*2=28をパスワードにして、 パラメータ設定でこの数値を入力しないとEAが稼働しないようにします。
extern int Passcode = 28;
//..OnInitとかOnDeinitとかの記述
void OnTick()
{
int GeneratedPass = StringToInteger(StringSubstr(IntegerToString(AccountNumber()),0,1))*4+
StringToInteger(StringSubstr(IntegerToString(AccountNumber()),1,1))*3+
StringToInteger(StringSubstr(IntegerToString(AccountNumber()),2,1))*2;
if( Passcode != GeneratedPass )
{
Comment("Passcode is wrong");
return;
}
//...メインコード
}
これはあくまでわかりやすく伝えるための簡単な計算式ですが、実際にはもっと複雑にします。
メリットとしては、EAを毎回コンパイルしなくていいことと、EAを先にばらまいてからパスワードを発行するという流れを取れることです。
サーバーで認証で口座縛りをかける
FXON(ゴゴジャン)のEAがやっている方法です。EAを使う=ネットにつながっているということなので、自サーバーにアクセスさせて、口座番号や口座名の認証を行います。
数ある口座縛りの中でも一番強固なプロテクトですが、気軽にやるには荷が重すぎます。デメリットとしてはEAからサーバーにアクセスしてもらうために、URL設定をしてもらうかDLLが必要になります。
今でこそWebRequestで簡単にhttpリクエストできますが、2014年以前はDLLを組まなければいけないわ、ユーザーにDLLをセットしてもらわなくてはいけないわ、で比較的大変でした。
（MT4のFTP機能を使えば間接的にアクセス自体はできましたが、FTPのログイン情報がなければ通信できないことを考えると、セキュリティの観点からは現実的ではありませんでした。）
しかし、一度作ってしまえば、たとえ誰かがEAをばらまいたとしても、サーバー側からいろいろと操作したり、情報収集することが可能です。(口座番号とか口座名とか資産データとか吸い出すこともその気になれば可能です。)
WebRequestとは、EAからWEBにアクセスする関数で、数行の記述で、ネットワークに接続することが可能です。
接続方法もGETメソッドとPOSTメソッドがあるので、ログインが必要なポータル系サイトでも、ログインして表示させたりすることもできます。
int WebRequest( const string method, // HTTP method const string url, // URL const string cookie, // cookie const string referer, // referer int timeout, // timeout const char &data[], // the array of the HTTP message body int data_size, // data[] array size in bytes char &result[], // an array containing server response data string &result_headers // headers of server response );
てきとうにレンタルサーバーを借りて、データベースを構築しておけば、 このWebRequestと併用することで、オンライン認証ができます。
この認証方法の場合、プログラムの組み方によっては、サーバー側からEAを稼働停止したり、リストを取得することができるという非常に強力なメリットがあります。
デメリットは、 開発者がMQL、SQL、PHP、HTML、(ちょっとした)サーバー構築、通信プロトコルの知識に精通していなければならないので、すこしハードルが高いということです。 サーバー系のプログラマとトレード系のプログラマは属性が全く違うので、意外とどちらもできるエンジニアというのは限られているみたいです。
MQL&PHP サーバーを経由するコピートレードシステムを作るやり方 についても１から解説していますので、余力がある方はトライしてみてください。
MQL&PHP サーバーを経由するコピートレードシステムを作るやり方1
有効期限をつけるやり方(超簡単バージョン)
EAやインジケーターをお試しで使ってもらい、気に入ってもらったら購入してもらうというビジネスモデルは、買い手にとっても売り手に取ってもメリットのある販売方法です。
そのためには、EA、インジケーターに有効期限機能をつける必要があります。 一番良いのはウェブサーバー認証方式にして管理することですが、簡易的にEAに制限をつけることもできます。
例えば、2019年10月1日から2019年12月31日までの間、 利用可能にしたい場合、
datetime ST,ET;
ST = StrToTime("2019.10.1 00:00");
ET = StrToTime("2019.12.31 00:00");
if( TimeCurrent() < ST ) return(0);
else if( TimeCurrent() > ET ) return(0);
これをOnCalculate（あるいはOnTickかOnStartかStart）の直下に貼り付ければ、 その期間だけ有効なＥＡ，インジケーターが出来上がります。
OnTick()
{
//ここに張り付ける
}
ここで注意してもらいたいのは、 日付のフォーマットです。 日付は、必ず半角で 2003.8.12 17:35 西暦.月.日 時:分 のフォーマットで記入してください。 「日」と「時」の間は、半角スペースです。
ワンタイムパスワードで口座縛りをかける
銀行アプリとかが最近導入している認証にワンタイムパスワードというものがあります。
これはその時、数分間だけ有効なパスワードというやつです。
逆に言うと、このワンタイムパスワードは時刻から生成されています。 これはEAの縛りにももちろん使えます。
たとえば、2017年5月の間だけEAをお試しで配布したいとします。 その場合、口座番号が1234567だったとして、2017と5から適当な四則演算をしてパスワードを生成します。（2017x5x1234567=12450608195）
このパスワードをEAと一緒に配布すれば5月の間だけ有効なEAができるわけです。
extern int PassCode = 12450608195;
//...OnInitとかの記述
void OnTick()
{
if( Year()*Month()*AccountNumber() != PassCode )
{
Comment("Trial is over.");
return;
}
//...メインコード
}
6月以降も引き続き利用する場合は、またワンタイムパスワードを発行すれば、EAを再配布する手間なしに、システムを実質的に継続利用させることができます。
※パスワードの生成アルゴリズムは推測されないように、実際にはもっと複雑にしましょう。
EAのトレードがコピートレードで流出するのを防ぐ方法
何かしらEAを配布するときには流出のリスクが伴います。EAそのものにアカウント縛りや、FX業者縛りなどをつけることが一般的ですが、他のチャートにコピートレードシステムを設置されると、リアルタイムでトレードデータが流出する可能性があります。
コピートレードでEAの口座縛りが突破されてしまう
これはどういうことかというと、例えば50,000円するEAが販売されていて、それを３つのアカウントで使用したいと考えています。そのEAに口座認証があり、複数のアカウント上で稼働させることはできない場合、３アカウント分の料金を払わなければいけません。（MQLのマーケットで販売されているEAがこのタイプです。）
しかし、一つのアカウント上でその有料EAを稼働させて、そのMT4にコピートレードシステムを稼働させれば、第二・第三のMT4にトレードをコピーすることが可能というわけです。
EAを利用する側からすればお得な使い方ですが、販売する側、提供する側からすると、何とかしてこれを阻止したいというわけです。
ちょっとした対策
解決法から言うと、
他のチャート、ファイル、グローバル変数、ログ上でコピーツールEAを稼働させないように記述すれば可能です。
EAをセットしているチャート以外のチャートを強制的に閉じさせる
コピーツールを稼働させるには、それが中継システムを経由するしないに関係なく、
少なくとも一つのチャート上に専用のEAなりスクリプトなりを設置しなければならないタイプが多いです。
EAでは他のチャートにアクセスして、それを閉じることができる関数
ChartFirst()、ChartNext()、ChartID、ChartCloseがあるので、これで自分以外のチャートを強制的に閉じます。
ファイル関数でアクセスできる位置にあるファイルをEAから全部削除させる
コピートレードツールがファイル関数でトレードデータを出力している可能性も高いので、定期的にファイル関数(FolderClean()など)で削除し続ける記述をします。ただし、ファイル名の推測ができていないとファイル名の取得の点がちょっと問題になります。
大量のダミーログを出力する
ログからコピートレードデータを引っ張ってくるパターンのツールもあるので、ダミーのログを大量に出力します。本当はオーダーを出していないのに”OrderOpen”などの文字列が入ったログを出力します。
グローバル変数をすべて削除する
可能性としては低いですが、グローバル変数を使っているツールの可能性もなくはないので、GlobalVariablesDeleteAll()で一応消しておきます。
チャート上のオブジェクトを定期的に強制削除する
これも可能性としては低いですが、チャート上のオブジェクトからトレードデータを取っている可能性もなくはないので、オブジェクトも排除します。
この対策のデメリット
この方法を使うともちろんデメリットもあります。
それは利用者からするとそのEAが稼働しているチャートしか開けないということです。
もし裁量トレードもする利用者であれば苦情がきてもしょうがないですね。事前告知は必須です。
しかし、この業界にはそれでもOKという層も比較的あって、特にMT4のアカウントだけ借りて疑似的にファンドをしているような層と取引する場合にはこういった処理は必要になるかと思います。
もしコピートレードを阻止するだけでなく、コピートレードされていることを遠隔で把握したい場合には、（”お仕置き”をしたい場合には）
サーバーを設置して、EAからサーバーにデータを流すシステムをあらかじめ設置しておく必要があります。
もともとがWEBアカウント認証方式の場合、データベースのテーブルの列にほかのチャートの情報を入れる列を作ればいいだけなので簡単です。
100%防げるわけではない
この方法の場合でも完全にコピートレードによるトレードの流出を防げるわけではありません。もし使わられているコピートレードシステムがEAに依存しない仕様のシステムの場合、突破される可能性があります。
具体的にはEAではなく、インジケーターの形式でコピーするとかです。しかし、その場合、コピー元はインジケーターで、コピー先はEAになるので、ユーザーフレンドリーなコピートレードシステムとは言い難いですね。
また、ファイル関数やログ出力でトレードデータを抜き取る、ということも考えられますが、安定性とスピードにかけるので、そういったコピートレードシステムもあまり優秀なシステムとは言えないと思います。（本題からはそれますけど…）