中央サーバーとのリモートインタラクションを実装する支払いシステム、登録サービス、およびその他のリソースを使用する必要がある場合、おそらく「ゲートウェイ」の概念に出くわしました。 これは、中央サーバー(ゲートウェイを備えたシステムのサーバー)と特定のクライアントのソフトウェアの間で電子メッセージを交換することにより、中央サーバーで操作を実行するように設計されたサービスです。
おそらく理想的なゲートウェイは、標準の自己文書化形式であり、そのサポートがすべての最新のプログラミング言語(さらにはハードウェアレベルでも)で実装されているため、XML形式でデータを送受信できるはずです。 さらに、XMLはUTF-8、UTF-16、さらにはUTF-32のUnicodeエンコーディングをサポートします。 簡単に、ただし例を使用して、単純なXMLゲートウェイを作成する原理について説明します。 リクエストの送信、シンプルさ、そして同時に、多様性のために、POST / GETメソッドの例を使用することを検討します。
まず、相互作用の概念を検討します。 あなたは、要求を受け入れ、処理し、入力された形式で要求された情報をクライアントに送信するサーバーです。
明確にするために、次の例を検討することを提案します。サーバー上に月額料金を提供する準備ができている情報資料の特定のデータベースがあります。 材料はカテゴリに分けられ、各パートナーがアクセスできるカテゴリに関する情報を含むパートナーのデータベースがあります。
パートナーがアクセスの制限内でのみ資料を受け取るためには、それを明確に識別する必要があります。 さもなければ、彼または他の知識のある人は予想以上にあなたから「引き抜く」ことができるでしょう、そして、これは色あせた評判と経済的損失に満ちています。 商業プロジェクトがあります。
識別の問題は、ゲートウェイに要求を行うサーバーのIPアドレスを参照して生成される一意のアクセスキーを使用してパートナーを発行することで解決できます。
たとえば、OJSC Shishkin Lesという会社があり、カテゴリ1、2、5、および9の素材への生涯アクセスを支払いました。会社のサーバーはディレクターのベッドの下に自宅にありますが、IPアドレスは静的で、12.34.56.78です。 次に、このパートナーの一意のアクセスキーを生成する必要があります。これは、次のように実行できます。
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
<?php define( 'SECRET_WORD' , 'LsXUS~J' ); function getUniqueKey($ip, $access) { return substr(md5($ip . SECRET_WORD . $access), 5, 20); } ?>
他の条件に関係なく一定である定数「SECRET_WORD」に注意してください。 getUniqueKey()関数は、サーバーIPアドレス($ ip = '12 .34.56.78 ')およびパートナーがアクセスできる折り畳まれたIDカテゴリの文字列($ access =' 1259 ')をパラメーターとして受け取ります。 次に、これらすべてのパラメーターからmd5ハッシュが生成され、15文字の文字列に切り捨てられます(この例では、5番目のハッシュ文字で始まります)。 これは、パートナーごとに生成される一意のキーです。 クライアントからのすべてのリクエストでキーの正当性をチェックします。
前に説明したように、クライアントはPOST / GETメソッドを使用してサーバーに要求を作成し、必要なパラメーターをそれらに渡すことができます。 そのようなクエリの例を考えてみましょう。
mysite.com/gateway.php?id=1&type=list&token=8381ad87b37986ac7bb6
そのため、ゲートウェイにリクエストを送信し、3つのパラメーターのみをゲートウェイに渡します。
- id = 1、システム上の個人クライアントID
- type = list、これは私が発明したパラメータであり、クライアントが何をどのような形式で受信したいかをサーバーに伝えます
- token = 8381ad87b37986ac7bb6、クライアントの一意のキー。認証用の各トランザクションでサーバーに送信します
ゲートウェイ(gateway.php)は、接続の信頼性を検証し、リクエストでクライアントに応答することしかできません。 ちなみに、キーが正しくない場合や、回答の取得/生成でエラーが発生した場合でも、クライアントは回答を受け取る義務があります。
ゲートウェイを照会するときは、キー検証機能を考慮してください。
- <?php
- 関数checkValidation($ clientID、$ clientToken){
- //クライアントIPアドレス
- $ clientRemoteAddr =(getenv( 'HTTP_X_FORWARDED_FOR' ))? getenv( 'HTTP_X_FORWARDED_FOR' ):getenv( 'REMOTE_ADDR' );
- //カテゴリへのクライアントアクセスレベル
- //実際には選択が必要です
- // $ clientIDによるクライアント許可
- $ clientAccessLevel = '1259' ;
- //正しいキー
- $ checkToken = getUniqueKey($ clientRemoteAddr、$ clientAccessLevel);
- //クライアントから検証および受信したキーの比較
- return ($ clientToken == $ checkToken);
- }
- ?>
したがって、checkValidation()関数がtrueを返す場合、接続認証が渡されます。 これで、回答の作成と準備を開始できます。
この例では、回答にはさまざまなカテゴリの特定の情報が含まれている必要があります。そのような選択には次のフィールドセットが含まれていると仮定します。
- element_id-特定の各レコードの識別子、一意
- category_id-レコードが属する見出しの識別子(この例では、クライアントは見出し1、2、5、9にアクセスできることを思い出してください)
- title-要素のタイトル
- テキスト-記録内容
- time-公開後の日付と時刻(日付形式は自分で選択してください)
この場合の答えの構造は次のようになります。
- <? xml バージョン = "1.0" encoding = "utf-8" ? >
- < 応答 >
- < エラーコード > 0 </ エラーコード >
- < コンテンツ >
- < アイテム >
- < element_id > 1 </ element_id >
- < category_id > 5 </ category_id >
- < タイトル >タイトル1 </ タイトル >
- < text >要素番号1のテキスト、すべてのゴミについて</ text >
- < 時間 > 1248770309 </ 時間 >
- </ アイテム >
- < アイテム >
- < element_id > 2 </ element_id >
- < category_id > 9 </ category_id >
- < タイトル >タイトル2 </ タイトル >
- < text >要素番号2のテキスト、すべてのゴミについて</ text >
- < 時間 > 1248770319 </ 時間 >
- </ アイテム >
- </ コンテンツ >
- </ 応答 >
操作が成功した場合の属性「error-code」はゼロに等しくなければなりません。これは、クライアントに「要求されたものよりも、すべて正常です」と文字通り言います。 エラーが発生すると、このエラーのコードがこの属性で送信されます(この場合、属性「content」とそのすべてのコンテンツは送信されなくなります)。
エラーハンドラが次の問題を認識しているとします。
- エラー100-キー検証エラー(トークンが正しくありません)
- エラー101-クライアントIDが渡されませんでした
- エラー102-一意のクライアントキーが転送されませんでした
- エラー201-要求された情報がデータベースに見つかりませんでした
- エラー202-要求された情報の選択中にエラーが発生しました
まあなど。 エラー応答は次のようになります。
- <? xml バージョン = "1.0" encoding = "utf-8" ? >
- < 応答 >
- < エラーコード > 102 </ エラーコード >
- </ 応答 >
考慮すべき最後のことは、そのような答えの形成です。 上記のような多くの実装があるかもしれませんが、私はそのような単純なオプションを提案します:
- <?php
- 関数sendResponse($コード、$コンテンツ= '' ){
- //属性を作成します
- 関数getNode($キー、$ 値 ){
- if ($ value != '' )){
- '<'を 返します。 $キー。 '>' 。 $ 値 '</' $キー。 '>' ;
- }
- }
- //追加フィールド
- $アイテム= '' ;
- // $コンテンツが空ではなく、配列の場合
- if (!empty($ content)&& is_array($ content)){
- foreach ($ content as $ key => $ value ){
- $ items。= '<ユーザー>' ;
- if (is_array($ value )){
- foreach ($ 値 としての $ skey => $ svalue){
- $ items。= getNode($ skey、$ svalue);
- }
- } else {
- $ items。= getNode($ key、$ value );
- }
- $ items。= '</ user>' ;
- }
- }
- //回答の形成と送信
- '<response> <error-code>'を出力します。 $コード。 '</ error-code>' $個のアイテム。 '</ response>' ;
- exit();
- }
- ?>
この短い記事がおもしろいことを願っています。 いくつかの改良を加えた提案された実装は、小さなリソースでの使用に非常に適しています。 トラフィックが多い場合、結果をキャッシュする必要がありますが、誰もがそれを知っていることを願っています。
コメントに批判、追加、その他の実装を歓迎します:-)