Session を使用して非 Web 端末を開発する方法

セッション|ウェブ

Session を使用して非 Web 端末を開発する方法





プロトコル

— 著者 sunggsun @ 20:27




Session (セッション) は、Web 上での情報対話のより効果的な手段です。使いやすさ、安定性、安全性、信頼性により、多くの Web 開発者に好まれています。特にインターネットの本人認証やオンライン電子ショッピングなどで広く使われています。偶然ですが、筆者が金融プロジェクトでデータセンター基盤を開発していた際、データ送信部分における本人認証や情報のやりとりがWeb分野におけるセッション制御によく似ていると感じました。そこで、この新しいテクノロジを試してみたいと思い、多くの情報を調べた結果、Web 以外のクライアントでの情報のやり取りに Session を使用することが可能であると感じました。テストを繰り返した結果、プロジェクトに適用することに成功し、さらに一時的なデータの保存や複雑なロック状態の検出が不要になり、状態はセッションによって自動的に維持されるようになりました。

良いことを独り占めすることはできません。著者は、Web 以外の開発にセッション制御をうまく適用するための重要な技術的ポイントについてお話したいと思います。 Web 上のユーザー セッションを追跡するために Cookie が最も一般的に使用される方法であることはわかっています。Cookie が無効になっている場合、セッションの追跡には通常 URL 書き換えが使用されます。では、クッキーとは一体何なのでしょうか？定義によれば、Cookie はサーバーからクライアントに送信され、クライアント環境に保存され、すべてのクライアント要求でサーバーに送り返される情報です。たとえば、IE を使用して電子ショッピング モールにログインすると、IE は商品一覧ページを取得するだけでなく、Set-Cookie の応答ヘッダー情報も受け取ります。この情報の形式は「Set-Cookie:NAME=VALUE;Comment=COMMENT;Domain=DOMAINNMAE;Max-age=SECONDS;Path=PATH;secure;Version=1*DIGIT」です。ここで、NAME 値のペア (区切り文字を使用します)セミコロンで区切ります) は必須ですが、残りはオプションです。最も重要な情報は、当然、必須の値のペアにも含まれます。VALUE は、この Cookie の識別子の値であり、他のいくつかのオプションの値のペアについては、http: を参照してください。 //www.faqs.org/rfcs/rfc2109.html。特定の商品を購入し、ショッピング リストをサーバーに送信すると、リクエスト ヘッダーに NAME 値のペアが自動的に追加されます。Cookie が無効になっている場合は、URL の書き換えが使用されて URL リクエスト アドレスに NAME 値が追加されます。 。 Web サーバーはこのリクエストを受信すると、Cookie が存在するかどうかを確認し、それに応じてセッションを追跡します。上記の分析から理解するのは難しくありません。実際、Web サーバーは Set-Cookie ヘッダー情報に依存してセッションを追跡し、認証のために NAME 値のペアを追跡します。 Web 以外の端末を使用して Web サーバーからの応答情報を受信し、そこから Cookie ヘッダー情報を解析し、再度 Web サーバーにリクエストを送信するときに、解析した Cookie 情報を追加することは Web サーバーで実行できるのではないでしょうか。これに基づいて本人認証を行うには？
上記の分析により、コードを書くのが非常に便利になります。以下は、作成者が C++Builder 6 アプリケーションを使用して Apache Tomcat 4.0 サービス エンジンでサーブレットと対話するデモ コードです。これは参照のみを目的としています。

C++ クライアントが初めてサーバーにリクエストを送信するときのコードは次のとおりです。
TIdHTTP *HTTPClient = new TIdHTTP(NULL);
String URL= "http://localhost:8080; /Rev/servlet/test ";
try
{
try
{
HTTPClient->Get(URL);
if (HTTPClient->Response != NULL)
{
hList = HTTPClient->Response-> ;ExtraHeaders;
String cookie = hList->Values["Set-Cookie"];
int pos = cookie.Pos(";");
if (pos > 0)
Session_ID = cookie.SubString(1, pos-1);
else
Session_ID = cookie;
}
} catch(Exception& E)
{
}
} __finally
{
HTTPClient->Free();
上記のコードポイントの変数 URL各シチュエーションの割り当てに従って、サーブレットの HTTP アドレスに変換されます。変数 Session_ID はグローバル変数であり、Cookie を記録します。次の対話中に、HTTPClient リクエストの前に「HTTPClient->Request->ExtraHeaders->Add("Cookie:" + Session_ID);」を追加するだけで、Apache Tomcat が有効性を自動的に判断します。単純？

サーブレット サーバーの有効性検証も、以下に示すように、Apach Tomcat エンジンによって比較的簡単に実行されます。 setContentType ("text/html; charset=GBK");
PrintWriter out = response.getWriter();
out.println("");
out.println("");
HttpSession session = request.getSession(false);
if (session != null) {
out. println("

本人確認

");
} else {
out.println("

認証に失敗しました

");
}
out.println("< ;/ body>");
}
コードの中で最も重要なのは「request.getSession(false);」です。パラメータが true の場合、Apache Tomcat は新しいセッションを作成します。パラメータが false の場合、Apache Tomcat は、リクエスト。したがって、セッションの永続性を維持したい場合は、パラメータ false を指定して呼び出す必要があります。ただし、セッションが長期間呼び出されない場合、Apache Tomcat はリソースを適切に使用するためにセッションを自動的に無効にします。 Apache Tomcat の管理メカニズムと構成については、http://jakarta.apache.org/ を参照してください。
このデモ コードは、C++Builder に付属する TIdHTTP コンポーネントを使用します。このコンポーネントは、Delphi にも同様の MFC があり、HTTP 仕様に従って実装されています。デバッグ時には、それぞれが使い慣れた開発プラットフォームを使用する必要があります。 認証に使用されるサーブレット プログラムが Apach Tomcat にロードされ、Apach Tomcat が再起動されます。上記のコードはデモンストレーションのみを目的としており、実際のアプリケーションでは、HTTPClient のリクエスト リクエスト パッケージとサーブレットのレスポンス レスポンス パッケージのさまざまな例外処理を追加する必要があります。興味のある方は、電子メール 21cnDeveloper@163.com を通じて作成者と連絡を取ることができます。