モバイル側とPHPサービス側インタフェースの通信フロー設計(基礎版)
4883 ワード
転載先:http://blog.snsgou.com/post-766.html
----->非オープンプラットフォーム
----->社内製品
インタフェースの特徴の要約:
1、非開放性のため、すべてのインタフェースは閉鎖的で、会社内部の製品に対してのみ有効である.
2、非開放的なので、OAuthのプロトコルは通用しません.中間ユーザーの授権プロセスがないからです.
3、アクセスするにはユーザーのログインが必要です.
4、少しインタフェースがあって、ユーザーのログインを必要としないでアクセスすることができます;
以上の特徴に対して,移動端とサービス端との通信には2つの鍵,すなわち2つのtokenが必要である.
最初のtokenはインタフェースのための(api_token);
2番目のtokenは、ユーザに対するものである(user_token).
まず最初のtoken(api_token)
その職責はインタフェースアクセスの隠蔽性と有効性を維持し、インタフェースが自分の人にしか使えないことを保証することです.どうすればいいですか.参考の考え方は以下の通りです.
サーバ側とクライアントが持つ共通属性によってランダムな列を生成し、クライアントはこの列を生成し、サーバも同様のアルゴリズムによって列を生成し、クライアントの列を検証します.
現在のインタフェースは基本的にmvcモードで、URLは基本的にrestfulスタイルで、URLの大体のフォーマットは以下の通りです.
http://blog.snsgou.com/モジュール名/コントローラ名/メソッド名?パラメータ名1=パラメータ値1&パラメータ名2=パラメータ値2&パラメータ名3=パラメータ値3
インタフェースtoken生成規則は次のように参照されます.
api_token=md 5('モジュール名'+'コントローラ名'+'メソッド名'+'2013-12-18'+'暗号化鍵')=770 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2
その中の
1、'2013-12-18'は当日の時間で、
2、「暗号鍵」は私有の暗号鍵であり、携帯電話側はサービス側で「インタフェース使用者」のアカウントを登録する必要がある.
フィールド名
フィールドタイプ
コメント
client_id
varchar(20)
クライアントID
client_secret
varchar(20)
クライアントキー
(注:コアフィールドのみがリストされていますが、その他は拡張しましょう!!)
サービス側インタフェース検査、PHP実現プロセスは以下の通り:
さらに2番目のtoken(user_token)
パスワードの漏洩を防ぐために、ユーザーのユーザー名とパスワードを複数回コミットすることを保護します.
インタフェースにユーザーログインが必要な場合、そのアクセスプロセスは次のとおりです.
1、ユーザーは「ユーザー名」と「パスワード」を提出し、ログインを実現する(条件は許可され、このステップはhttpsを行ったほうがいい).
2、ログインに成功した後、サービス側はuser_を返します.token、生成ルールは次のように参照されます.
user_token=md 5('ユーザのuid'+'Unixタイムスタンプ')=etye 0 fgkgk 4 ca 2 aabd 20 ae 9 a 5 dd 77471 fgf
サービス側用データテーブルメンテナンスuser_tokenのステータスは、次のように設計されています.
フィールド名
フィールドタイプ
コメント
user_id
int
ユーザID
user_token
varchar(36)
ユーザtoken
expire_time
int
有効期限(Unixタイムスタンプ)
(注:コアフィールドのみがリストされていますが、その他は拡張しましょう!!)
サービス側生成user_token後、クライアント(自己記憶)に戻り、クライアントがインタフェース要求のたびに、インタフェースにユーザーログインしてアクセスする必要がある場合はuser_idとuser_tokenはサービス側に返され、サービス側はこの2つのパラメータを受け入れた後、以下のステップを行う必要があります.
1、検出api_tokenの有効性;
2、期限切れのuserを削除するtokenテーブルレコード;
3、user_によるid,user_tokenはテーブルレコードを取得し、テーブルレコードが存在しない場合はエラーを直接返し、レコードが存在する場合は次のステップに進む.
4、user_の更新tokenの期限切れ(延期、有効期間内の連続操作がオフラインにならないことを保証する);
5、インタフェースデータを返す;
インタフェースの例は次のとおりです.
1、配布ログ
URL: http://blog.snsgou.com/blog/Index/addBlog?client_id=wt3734wy636dhd3636sr5858t6&api_token=880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
要求方法: POST
POSTパラメータ:title=私はタイトル&content=私は内容です
データを返します.
{ 'code'=>1,//1:成功0:失敗 'msg'=>'操作成功'//ログイン失敗、アクセス権なし 'data' => [] }
----->非オープンプラットフォーム
----->社内製品
インタフェースの特徴の要約:
1、非開放性のため、すべてのインタフェースは閉鎖的で、会社内部の製品に対してのみ有効である.
2、非開放的なので、OAuthのプロトコルは通用しません.中間ユーザーの授権プロセスがないからです.
3、アクセスするにはユーザーのログインが必要です.
4、少しインタフェースがあって、ユーザーのログインを必要としないでアクセスすることができます;
以上の特徴に対して,移動端とサービス端との通信には2つの鍵,すなわち2つのtokenが必要である.
最初のtokenはインタフェースのための(api_token);
2番目のtokenは、ユーザに対するものである(user_token).
まず最初のtoken(api_token)
その職責はインタフェースアクセスの隠蔽性と有効性を維持し、インタフェースが自分の人にしか使えないことを保証することです.どうすればいいですか.参考の考え方は以下の通りです.
サーバ側とクライアントが持つ共通属性によってランダムな列を生成し、クライアントはこの列を生成し、サーバも同様のアルゴリズムによって列を生成し、クライアントの列を検証します.
現在のインタフェースは基本的にmvcモードで、URLは基本的にrestfulスタイルで、URLの大体のフォーマットは以下の通りです.
http://blog.snsgou.com/モジュール名/コントローラ名/メソッド名?パラメータ名1=パラメータ値1&パラメータ名2=パラメータ値2&パラメータ名3=パラメータ値3
インタフェースtoken生成規則は次のように参照されます.
api_token=md 5('モジュール名'+'コントローラ名'+'メソッド名'+'2013-12-18'+'暗号化鍵')=770 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2
その中の
1、'2013-12-18'は当日の時間で、
2、「暗号鍵」は私有の暗号鍵であり、携帯電話側はサービス側で「インタフェース使用者」のアカウントを登録する必要がある.
フィールド名
フィールドタイプ
コメント
client_id
varchar(20)
クライアントID
client_secret
varchar(20)
クライアントキー
(注:コアフィールドのみがリストされていますが、その他は拡張しましょう!!)
サービス側インタフェース検査、PHP実現プロセスは以下の通り:
01 <?php 02 // 1、 GET 03 $module = $_GET [ 'mod' ]; 04 $controller = $_GET [ 'ctl' ] 05 $action = $_GET [ 'act' ]; 06 $client_id = $_GET [ 'client_id' ]; 07 $api_token = $_GET [ '' api_token]; 08 09 // 2、 client_id ， ， client_secret 10 $client_secret = getClientSecretById( $client_id ); 11 12 // 3、 api_token 13 $api_token_server = md5( $module . $controller . $action . date ( 'Y-m-d' , time()) . $client_secret ); 14 15 // 4、 api_token api_token ， ， 16 if ( $api_token != $api_token_server ) { 17 exit ( 'access deny' ); // 18 } 19 20 // 5、 ， 21 //。。。 22 ?> さらに2番目のtoken(user_token)
パスワードの漏洩を防ぐために、ユーザーのユーザー名とパスワードを複数回コミットすることを保護します.
インタフェースにユーザーログインが必要な場合、そのアクセスプロセスは次のとおりです.
1、ユーザーは「ユーザー名」と「パスワード」を提出し、ログインを実現する(条件は許可され、このステップはhttpsを行ったほうがいい).
2、ログインに成功した後、サービス側はuser_を返します.token、生成ルールは次のように参照されます.
user_token=md 5('ユーザのuid'+'Unixタイムスタンプ')=etye 0 fgkgk 4 ca 2 aabd 20 ae 9 a 5 dd 77471 fgf
サービス側用データテーブルメンテナンスuser_tokenのステータスは、次のように設計されています.
フィールド名
フィールドタイプ
コメント
user_id
int
ユーザID
user_token
varchar(36)
ユーザtoken
expire_time
int
有効期限(Unixタイムスタンプ)
(注:コアフィールドのみがリストされていますが、その他は拡張しましょう!!)
サービス側生成user_token後、クライアント(自己記憶)に戻り、クライアントがインタフェース要求のたびに、インタフェースにユーザーログインしてアクセスする必要がある場合はuser_idとuser_tokenはサービス側に返され、サービス側はこの2つのパラメータを受け入れた後、以下のステップを行う必要があります.
1、検出api_tokenの有効性;
2、期限切れのuserを削除するtokenテーブルレコード;
3、user_によるid,user_tokenはテーブルレコードを取得し、テーブルレコードが存在しない場合はエラーを直接返し、レコードが存在する場合は次のステップに進む.
4、user_の更新tokenの期限切れ(延期、有効期間内の連続操作がオフラインにならないことを保証する);
5、インタフェースデータを返す;
インタフェースの例は次のとおりです.
1、配布ログ
URL: http://blog.snsgou.com/blog/Index/addBlog?client_id=wt3734wy636dhd3636sr5858t6&api_token=880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
要求方法: POST
POSTパラメータ:title=私はタイトル&content=私は内容です
データを返します.
{ 'code'=>1,//1:成功0:失敗 'msg'=>'操作成功'//ログイン失敗、アクセス権なし 'data' => [] }