セッション
クッキーは、ユーザの、$Session 支援のためにデフォルトで使用されます。(オブジェクト )を参照)。ウェブユーザを追跡し、かつそのクライアントにサーバ側データを関連させるために、ウェブサーバをセットします。また、ウェブクライアントは、セッション id 確認のため、32 バイトで、クッキーを返します。この実装は非常に安全で、安全な HTTPS での一連の処理の中で使用されるかもしれないし、SecureSession と ParanoidSessionのセッティングでは、より強力になるかもしれません(設定を参照)。
本来、クッキーはグッドな(良い情報を含む)もので、HTTP でのリクエスト間の、持続的な、state(状態)管理のためにあります、しかしながら、クッキーは、JavaScript セキュリティに関連し安全上のリスクがあり、大規模なデータ追跡を行う会社によるプライバシー乱用の元であると集中砲火を浴びてきました。
こうした理由で、ウェブユーザは、時に、クッキーをオフにしており、通常の ASP セッション変換の実装は、無効になっています。したがって、リクエスト度に新たな、$Session が生成されます。このことは、ASP スタイルのセッションにとって良好な結果にはなりません。
クッキーのないセッション
*** 以下の《注意》を参照のこと ***
そこで、SessionQuery* (設定)のセッティングで、クッキーが拒否された場合、開発者が、URL 問い合わせ文字列の中に埋め込める方法を実装しました。ユーザが、クッキーをオンにした時は、クッキーが使われますが、オフの時は、セッション id は、URL のドキュメントに構文解析されるでしょう。
開発者がクッキーのないセッションを実装する、最初の一番容易な方法は、
SessionQueryParse* 指令で、取り急ぎ、Apache::ASP が、セッション id を、
URL のドキュメントに構文解析できるようにすることです。
このリソースが効果的でないなら、SessionQuery* 指令で、$Server->URL($url,\%params) メソッドで、問い合わせ文字列に、セッション id を含んだ、カスタムな、URL を生成させることです。
これらのクッキーのないセッションが動いている様子は、
./site/eg/session_query_parse.asp の実例で確認してください。
*** 《注意》 ***
この方法を使用するなら、問い合わせ文字列内の、セッション id を操作する際、
ページから他のサイトへのリンクには十分に注意を払ってください。
このセッション id は、リンクの相手方の、HTTP_REFERER(参照したサイト名)
ログに記載され、悪意あるハッカーがこの情報を利用して、たとえ、安全な
ウェブサーバが稼動していても、あなたのサイトの$Session でのセキュリティ
を危うくしかねません。
ユーザから離れたサイトにリンクする場合、セッション id を HTTP_REFERER
(のログ)に記載されないためには、以下のように、ユーザをそこに導くべく、
リンクを転送ページに向けるべきです。
<%
# sanitized_url:消毒した(安全な) URL
# OffSiteUrl:離れたサイト URL
# "クロスサイトでのバグ" 予防
my $sanitized_url =
$Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
%>
<html>
<head>
<meta http-equiv=refresh content='0;URL=<%=$sanitized_url%>'>
</head>
<body>
離れたサイトへ転送しています
<a href=<%=$sanitized_url%> >here</a>...
</body>
</html>
ウェブブラウザは、<meta> タグで、転送される前に、実際のページを訪れるので、HTTP_REFERER (の対象)は、このページにセットされ、問い合わせ文字列内の、セッション id は、このページにリンクされることはありません。
残念なことに、単純な $Response->Redirect() は、ここでは動作しません。
ウェブブラウザは、通常の転送が使用された時のみ、オリジナルなウェブページの
HTTP_REFERER を維持するからです。