| Oracle® Fusion Middleware Oracle WebCenter Sitesでの開発 12c (12.2.1.2.0) E82734-02 |
|
 前 |
 次 |
セッションには訪問者の情報が格納され、Cookieにはセッション間で引き継がれる訪問者の情報が格納されます。セッションおよびCookieを効率よく管理する場合に役立つ例およびヒントを参照してください。
トピック:
Webサイトを管理するWebサーバーで、セッション情報を保持するためにWebサーバーを必要としないステートレスなHTTPプロトコルを使用する場合には、セッションが必要です。訪問者がページの参照を開始すると、ただちにアプリケーション・サーバーがセッションを開始します。参照している情報は、セッション変数に格納されます。
mainおよびwaterという2つのページが含まれているWebサイトを考えてみましょう。訪問者は最初にmainを見た後でwaterに移動するとします。そのため、標準的なWebサーバーでこのサイトを管理している場合、mainで収集されたナレッジは訪問者がwaterに移動したときに失われてしまいます。つまり、waterでは、訪問者がmainで提供できた可能性のある情報を利用できないことになります。
この制約を回避するために、アプリケーション・サーバーは訪問者が最初にWebサイトに入った時点を検出します。その時点で、アプリケーション・サーバーは訪問者に対してセッションを開始します。前述の例では、訪問者がmainページをリクエストした時点でアプリケーション・サーバーはセッションを開始しています。Webサイト・デザイナはmainを使用して訪問者に関する情報を収集し、その情報をセッション変数に格納できます。セッション変数に格納された情報は、すべての後続ページで利用できます。したがって、たとえばBobが自分の年齢をmainに指定して、mainのデザイナがその年齢をセッション変数に書き込んだ場合、waterではBobの年齢に簡単にアクセスできます。
セッション変数に格納された値は、そのセッションが継続する間は使用できます。セッションが終了すると、アプリケーション・サーバーはそのセッションに関連付けられたセッション変数を破棄します。各セッション変数はアプリケーション・サーバー上でメモリーを消費するため、不必要なセッション変数の作成はパフォーマンスの低下につながります。
WebCenter Sitesでは一部のセッション変数が自動作成されますが、Webサイト開発者はオプションとしてその他のセッション変数を作成できます。アプリケーション・サーバーは、セッションをクラスタ上で保持できます。
セッションは、訪問者が初めてWebサイトを訪れたときに始まります。これは、訪問者がブラウザを終了したり、システム管理者がアプリケーション・サーバーを停止したり、セッションがタイムアウトすると、終了します。
WebCenter Sitesは、cs.timeoutプロパティを使用してセッション・タイムアウト値をアプリケーション・サーバーに設定します。このプロパティを300に設定した場合、ユーザー・セッションは300秒、すなわち5分で無効になります。
次のトピックを参照してください。
セッションが作成されると、WebCenter Sitesは、この表で説明されているセッション変数を自動的に作成します。
表17-1 セッション変数
| セッション変数 | 保持される内容 |
|---|---|
|
ログインした訪問者の |
|
この訪問者が属するすべてのACLのカンマ区切りリスト。訪問者が明示的にログインしていない場合、デフォルトACLは |
|
訪問者のログイン時のユーザー名。訪問者が明示的にログインしていない場合、デフォルトのユーザー名は |
|
WebCenter Sitesのプロパティが含まれているファイルの名前。 |
訪問者が初めてサイトを訪れると、WebCenter Sitesでセッションが作成され、訪問者はDefaultReaderとして暗黙的にログインされます。セッション中に訪問者が明示的にログインした場合、WebCenter SitesはSessionVariables.currentUser, SessionVariables.currentAclおよびSessionVariables.usernameの値を自動的に更新します。ログインによって、その他のセッション変数の値が影響を受けることはありません。つまり、ログイン前にページでセッション変数が作成された場合、その値はログイン後も有効です。訪問者が明示的にログアウトすると、WebCenter Sitesで生成されたセッション変数はログイン前に保持されていた値に自動的に戻ります。たとえば、次の順序を考えてみましょう。
訪問者が初めてページにアクセスした場合、SessionVariables.usernameの値はDefaultReaderです。
訪問者がmarilynとしてログインすると、SessionVariables.usernameの値はmarilynになります。
marilynがログアウトすると、SessionVariables.usernameの値はDefaultReaderに戻ります。
ログアウトをトリガーするには、<CATALOGMANAGER>タグをftcmd=logout修飾子と同時に呼び出します。このタグを発行すると、オプションとして、現在のセッションを破棄するkillsession修飾子を指定できます。さらに、<CATALOGMANAGER>タグをftcmd=login修飾子と同時に呼び出すことによって、セッションを新規作成できます。
数個のエレメントによるセッションの簡単な例を見ると、セッションの仕組みがわかるようになります。
次に、3つの非常に短いエレメントで構成される例を示します。
表17-2 セッションの例
| エレメント | 動作 |
|---|---|
|
訪問者に現在の気分を指定するように依頼します。 |
|
現在の気分をセッション変数に割り当てます。 |
|
セッション変数を評価します。 |
次のトピックを参照してください。
フィーリング・フォームは実際にはセッションまたは変数を含んでいません。このエレメントは、単にフォームを生成するのみです。訪問者の選択した気分は、次のようにSetFeelingエレメントに渡されます。
<form action="ContentServer" method="post">
<input type="hidden" name="pagename"
value="CSGuide/Sessions/SetFeelings"/>
<P>How are you feeling right now?</P>
<P>
<select name="Feeling" size="1">
<option>Good</option>
<option>Not so Good</option>
</select>
</P>
<P><input type="submit" name="doit" value="Submit"/></P>
</form>
結果のページは次のようになります。
「送信」ボタンをクリックすると、訪問者はSetFeelingに転送されます。このエレメントにより、訪問者の気分はCurrentFeelingという新規のセッション変数に割り当てられます。
<SETSSVAR NAME="CurrentFeeling" VALUE="Variables.Feeling"/> <P>Welcome to our site.</P> <P>Now proceed to <A href="ContentServer?pagename=CSGuide/Sessions/Meat"> some meaty content. </A></P>
この結果、次のようなページが生成されます。
Welcome to our site. Now proceed to some meaty content.
このアプリケーションのエレメントが訪問者にログインするよう要求した場合、WebCenter Sitesはusernameセッション変数を自動的に訪問者のログイン名に設定します。その場合は、ようこそメッセージをSetFeelingで次のようにパーソナライズすることもできます。
<P>Welcome to our site, <CSVAR NAME="SessionVariables.username"/> </P>
「some meaty content」をクリックすると、訪問者はMeatページに転送されます。このページでは、セッション変数が評価されます。
<IF COND="SessionVariables.CurrentFeeling=Good">
<THEN>
<P>Sessions are happiness.</P>
</THEN>
<ELSE>
<P>Don't let sessions get you down.</P>
</ELSE>
</IF>
気分のすぐれない訪問者には、次のメッセージが表示されます。
Don't let sessions get you down.
CurrentFeelingがMeatに対してどのように使用可能になったかに注目してください。実際に、CurrentFeelingはセッション内のその他すべてのエレメントでも使用可能です。
Cookieは、アプリケーションが訪問者のブラウザに書き込む文字列です。Cookieには、セッションを継続している訪問者に関する情報が格納されます。訪問者のブラウザは、この文字列を訪問者のディスク上の特別なCookieに書き込みます。訪問者がWebサイトに戻ったときに、訪問者のブラウザはCookieを設定したWebサーバーにCookieのコピーを返送します。Cookieは、作成されるとただちに、ページ上のエレメントの変数として使用可能になります。
たとえば、アプリケーションで訪問者のお気に入りのスポーツ・チームがCookieに格納されているとします。その場合は、訪問者が戻ったときにアプリケーションはCookieを取得し、その情報を使用してチーム・ロゴをバナーに表示することもできます。Cookieが不要に成った場合は、削除できます。
この項には次のトピックが含まれます:
CookieServerは、ユーザーにかわってCookieを設定するサーブレットです。CookieServerにアクセスするには、satellite.cookieタグを使用してCookieを作成します。
WebCenter Sitesには、Cookieの管理用に次の2つのタグがあります。
表17-3 Cookieのタグ
| タグ | 使用法 |
|---|---|
|
クライアントのブラウザにCookieを設定します。 |
|
クライアントのブラウザからCookieを削除します。 |
Cookieの値を取得する特殊なタグはありません。かわりに、訪問者がWebサイトに戻ると、WebCenter SitesはCookieの値を標準変数としてロードします。
(satellite.cookieを呼び出すことにより)Cookieを作成するときに、次の属性を指定できます。
表17-4 Cookieの属性
| 属性 | 値 |
|---|---|
|
Cookieの名前。これは、Cookieの値が含まれている受信変数の名前としても機能します。 注意: WebCenter Sitesのページ・コンテキストのCookieは、変数として扱われます。したがって、Cookieとアセット属性の名前が同じであれば、同じ変数として扱われます。 |
|
Cookieが今後Webサーバーに送信されなくなるまでの時間(秒)。 |
|
オプションとして、Cookieにセキュリティを設定します。 |
|
CookieがこのURLのみで送信されるように制限します。 |
|
Cookieが指定されたドメインのURLのみに送信されるように制限します。 |
一部の訪問者は、Cookieはセキュリティ上の脅威と感じて、Cookieを拒否するようにブラウザを構成することがあります。Cookieの情報が重要である場合に備えて、アプリケーションを構成する必要があります。
任意のタグを使用してコンテンツを訪問者のブラウザに戻す前に、Cookieの設定または削除を行う必要があります。<HTML>タグを使用する前であっても、Cookieの設定または削除が必要です。
数個の短いエレメントによるCookieの例を見ると、Cookieの仕組みがわかるようになります。
次はその例です。
表17-5 Cookieのエレメント
| エレメント | 動作 |
|---|---|
|
Cookieが設定されているかどうかを判別します。Cookieが設定されている場合は、 |
|
訪問者にお気に入りの色を選択するように要求するフォームを表示します。 |
|
この訪問者のブラウザにCookieを作成します。その後で、訪問者を |
|
簡単なようこそメッセージを訪問者のお気に入りの色で表示します。 |
次のトピックを参照してください。
Start.xmlエレメントは、Cookieが設定されているかどうかを判別します。Cookieが設定されている場合、WebCenter Sitesはその値をVariables.ColorCookieという標準変数に格納します。Start.xmlのコードは次のようになります。
<IF COND="IsVariable.ColorCookie=true">
<THEN>
<CALLELEMENT NAME="CSGuide/Sessions/DisplayWelcome"/>
</THEN>
<ELSE>
<CALLELEMENT NAME="CSGuide/Sessions/ColorForm"/>
</ELSE>
</IF>
ColorForm.xmlエレメントは、訪問者のお気に入りの色を収集するHTMLフォームを表示します。ColorForm.xmlのコードは次のようになります。
<form action="ContentServer" method="post">
<input type="hidden" name="pagename" value="CSGuide/Sessions/CreateCookie"/>
<P>What is your favorite color?</P>
<P>
<select name="FavoriteColor" size="1">
<option>Red</option>
<option>Green</option>
<option>Blue</option>
</select>
</P>
<P><input type="submit" name="doit" value="Submit"/></P>
</form>
CreateCookie.xmlエレメントは、ColorCookieというCookieを訪問者のブラウザに送信します。訪問者がCookieを無効化した場合、ブラウザはCookieを設定するようにというリクエストを無視します。訪問者がCookieを有効化した場合(デフォルト)、ブラウザはCookieをこのシステムのCookieファイルに書き込みます。
次に、CreateCookie.xmlのコードを示します。
<satellite.cookie NAME="ColorCookie" VALUE="Variables.FavoriteColor" TIMEOUT="31536000" SECURE="false"/> <CALLELEMENT NAME="CSGuide/Sessions/DisplayWelcome"/>
このコードでは、Cookieの値が訪問者のお気に入りの色に設定されます。このCookieは1年間(31,536,000秒)継続します。
DisplayWelcomeが呼び出されるときまでに、Cookieが設定されます。次のコードでは、ようこそメッセージを訪問者のお気に入りの色で表示するためにCookieの値が使用されます。
<H1><font color="Variables.ColorCookie"
REPLACEALL="Variables.ColorCookie">
Displaying a Friendly Welcome.
</font></H1>
セッションの使用に関するヒントとコツは、システム・リソースを効率よく使用しながら、訪問者の閲覧体験を改善する場合に役立ちます。
次の提案が役に立つ場合があります。
クラスタでは、セッション状態をクラスタ・メンバー全員にレプリケートする必要があります。クラスタでは、セッション・サイズを最小限に抑え、1クライアントにつき2キロバイトを超えるセッションを格納しないようにしてください。
妥当なセッション・タイムアウト値を決定します。設定するタイムアウト値が大きすぎると、システム・リソースが拘束されてしまいます。タイムアウト値が小さすぎると、訪問者は何回もログインしなければなりません。
パーソナライズしたコンテンツを訪問者に提供するWebサイトでは、セッションの追跡が必要です。WebCenter SitesとSatellite Serverは、どちらもセッションを追跡し、訪問者のブラウザに2つのCookieを設定します。各Cookieは、それぞれ個別にセッションを追跡します。この冗長性は、Satellite Serverが停止したときにWebCenter Sitesセッションを維持するために有用です。
Satellite Serverはセッション固有のページレットを最初の依頼者に返送するだけですが、ユーザーのログアウトに関するセッション固有の情報を明示的にフラッシュすることで、Satellite Serverキャッシュの領域が確保されます。
次の各セクションでは、Satellite Serverからセッション情報をフラッシュする方法について説明します。
特定のセッションに関連するすべてのデータをフラッシュできます。これは、フォームを次のフォーマットでURLにポストすることで、WebCenter Sitesから実行します。
https://host:port/servlet/FlushServer?reset=true&username=username&password=password&ssid=sessionID
ここで:
表17-6 セッション・パラメータ
| パラメータ | 値 |
|---|---|
|
キャッシュがフラッシュの対象となるSatellite Serverホストの名前を指定します。 |
|
Resinを別のポートで実行するように再構成した場合を除き、80(デフォルト)を指定します。 |
|
ユーザー名プロパティに割り当てられた値を指定します。 |
|
パスワード・プロパティに割り当てられた値を使用します。 |
|
削除対象のセッションを表すセッションID (Satellite Serverではなく、WebCenter Sitesにより保持されているもの)を指定します。 |
現在使用しているSatellite Serverセッションの情報をフラッシュするには、現行セッションIDを持つFlushServer URLを使用します。現行セッションID (ssid)は、アプリケーション・サーバーに依存する名前を持ったセッション変数に格納されます。この名前を確認するには、セッション変数HTTP_COOKIEを参照します。
次のJavaコードは、現行セッションの情報のフラッシュに使用します。
String value; String name = "WebLogicSession"; value = ics.GetVar(name); String sFlushSessionUrl ="http://mysatellite:80/servlet/ FlushServer?username=ftuser&password=ftuser& reset=true&ssid=" + value;" String sSatTest1Results = Utilities.readURL(sFlushSessionUrl);
