モバイル端末とPHPサーバーインターフェースの通信処理設計の強化版

前述の通り: モバイル端末とPHPサーバーインターフェースの通信処理設計(基本編)

api_tokenの検証のため、セキュリティをさらに強化することができます:

強化1:

さらに2つ追加 の2つがありますテーブル、1 つのインターフェーステーブル、1 つの認可テーブル の設計リファレンスは次のとおりです:

インターフェーステーブル

フィールド名フィールドタイプnoteapi_idイントインターフェースIDapi_namevarchar(120)blog/Index/addBlogなど、「/」を境界線とするインターフェース名api_domainvarchar(256)Domain is_enabledint API 番号api_name varchar(120)blog/Index/addBlog など、「/」を境界線とするインターフェース名

tinyint（1）	は利用可能です。その他 もう一度展開してください!

is_enabled

tinyint(1) が利用可能 1: 利用可能 0: 利用不可

add_timeint追加時間(スタンプ)expire_timeint有効期限(スタンプ) ページに 5 元と入力しました。相手に5元送金したいのですが、その結果、HTTP送金の途中で何者かに乗っ取られ、アカウントが「ハッカー」のアカウントに変更されてしまいました。考えてみると、この問題には 2 つの解決策があるはずです パラメータ名1=パラメータ値1identity_key (名前は重要ではありません)、このパラメーターの値は です。最初のいくつかのパラメーター値は順番に追加され、結果が暗号化されます。 identity_key = md5('パラメータ値 1' + 'パラメータ値 2' + 'パラメータ値 3' + '暗号化キーパラメータ名2=パラメータ値2

(注: コアフィールドのみがリストされており、その他は拡張してみましょう! )	実行プロセスは次のとおりです:	1. モバイル端末とサーバーによって生成された api_token を比較します。等しくない場合は、次のステップに進みます。インターフェース URL に従って、api_name と、クライアントからパラメーターとして返された client_id を組み合わせて、「認可テーブル」レコードを検索します。レコードが存在し、有効である場合 (使用可能かどうか、有効期限が切れているかどうか)、これは意味します。パーミッションの検証に合格し、インターフェイス データが返されるか、それ以外の場合はエラー メッセージが返されます。つまり、http リクエストがハイジャックされ、渡されたパラメータが改ざんされている可能性があると感じます。例を示します。
オプション 1: https を使用します。これは当てはまりません。 もっと言えば、これは比較的認識されているセキュリティ メカニズムです。	オプション 2: デジタル署名、その実装。原則は次のとおりです:	httpリクエスト、次の3つのパラメータを渡す必要がある場合
パラメータ名2=パラメータ値2	パラメータ名3=パラメータ値3	別のパラメーターを追加できます。パラメーターの名前は
	つまり:
');	したがって、渡される最終パラメータは次のとおりです。	パラメータ名1=パラメータ値1

パラメータ名3=パラメータ値3

client_id=client_id値

identity_key=md5('パラメータ値1' + 'パラメータ値2' + 'パラメータ値 3' + 'client_id 値' + '

暗号化キー

')

パラメータを受信した後、サーバーは、サーバーの

identity_key とクライアントの同じ暗号化ルールに従って identity_key

を再生成します。端末上の

identity_key

が等しくない場合、それは改ざんされていることを意味します。

以上は、モバイル端末と PHP サーバー インターフェイス間の通信プロセス設計の強化版をさまざまな側面を含めて紹介しましたが、PHP チュートリアルに興味のある友人の参考になれば幸いです。