Token Session Store Interceptorの使い方 - Struts 2+Spring 2+Tiles+Acegi+iBatis+GWT+JUnit 4+JMockit でフルスタックJAVAフレームワーク
使い方と言っても、TokenInterceptorと殆ど変わらない。 で、何が違うのかというと、通常トランザクションTokenでTokenが違う場合エラーメッセージや他の画面を表示する事になるが、これだと誤って２重ポストをした消費者にはエラー画面が表示され、完了画面にお目にかかる事ができない。 そこで、TokenSessionStoreInterceptorの登場となる。こちらはAction結果のValueStackの内容をToken処理後にSessionに記録してくれ、２重ポストのリクエストが来たときにSessionからValueStackを再構築して、あたかも元々のリクエストのように結果画面を表示してくれる。 これで、２重ポストをしてしまった消費者も目出度く完了画面を見ることができ、表示されている問い合わせ番号をメモすることができる。 ちょっとTIPS：ValueStackをSessi
CakePHPでデータベースセッションを使った時の怪現象
CakePHP1.3.5でのお話。 CakePHPを配置するWebサーバーを複数台でロードバランスしている環境でセッションを使おうと思ったら、ファイル以外にセッションを保存しないといけません。そういった理由で、セッションをデータベースに保存しているシステムがあります。このシステムでデータベースに保存されているセッションが突然全消しされる怪現象が何度か起こってて、なんじゃこりゃ(´・ω・`)ショボーンな感じで、原因究明に3日ぐらいかかった。忘れないうちにその全貌を書き残しておこう。 1. 問題部分 CakePHPでデータベースにセッションを保存している場合、有効期限が切れた時、PHPのsession_destroy関数が呼ばれて、それをトリガーにcake/libs/cake_session.phpの__destroyメソッドが呼ばれます。 function __destroy($id) {
Prefix routing毎にセッションCookieのセッション名を切り替える。CakePHP1.3 - kanonji’s diary
CakePHP 1.3.0から少し変わった Prefix Routing で、管理画面や携帯サイトなど、ディレクトリで分けた別サイトっぽく出来ます。 ただ、同じController/Modelクラスを使うし、config系も共有しています。 実態としては同じサイトの一部という感じです。 そこで気になるのは、セッションCookieがどうなるかと言う事です。 何かの間違いで*1PCサイトにログインしたセッションで、管理画面にログイン済み扱いになるみたいな事は避けたい。 なので、セッション名を違うものにして、混ざらないようにしたいです。 Prefix routing設定例 <?php Configure::write('Routing.prefixes', array('admin', 'mobile', 'dev')); APP/config/core.php http://www.examp
CakePHP 2.x 系で会員認証 / ログイン関係の機能を AuthComponent を使って構築する方法
CakePHP 2.1 でオリジナル CMS を構築する際に管理者やスタッフがログインできるような機能を構築します。この記事に書いてあることを理解すれば大抵の会員登録関係の仕組みは構築できるようになるので、構築をしたことない方は参考にしてみてください。 今回参考になったページは以下となります。 Authentication — Cookbook v2.x documentation (Auth コンポーネント) AuthComponent の設定を変更する – Kayaking Lifestyle (Field 名の変更) [CakePHP] セッション関連の設定 | HAPPY*TRAP (CakePHP の Session) セッション処理関数(session) (Session のおさらいの参考) Twitter でも数人の方からアドバイスを頂きました。この場を借りてアドバイスをくだ
サーブレットの様々なサンプル - セッションの管理 -
セッションについて Java サーブレットは HTTP プロトコルを使用します。HTTP はステートレスプロトコルです。 サーバは、リクエストを受け取ってレスポンスを返すと、クライアント ( ブラウザ ) との接続を終了します。 サーバにはクライアントを一意に識別できる情報を持っていないため、クライアントの情報は維持されません。 ( サーバはどのクライアントがどの情報を持っていたかを判断できない。 ) 上記の問題を解決するための仕組みがセッション管理となります。 セッションとは、簡単に説明するとクライアントがサーバに接続してから切断するまでの 1 接続単位です。 一般的には 1 リクエスト単位ではなく、例えば、ユーザがログインしてからログアウトもしくは、 ブラウザを閉じるなどの操作を行うまでの間を表します。 1 セッションの間には、複数回のリクエスト送信、レスポンス受信が
[ThinkIT] 第8回：Cookieとセッション情報 (1/3)
サーバ／クライアント間の通信を担当するHTTPは、ステートレス（状態を管理しない）なプロトコルです。このように表現してしまうと難しく聞こえるかもしれませんが、要するに「複数のページ間で情報を保持することができない」ということです。 例えば、ページXとページZという2つのページがあったとします。ページXを処理したあとにページZを呼び出したとしても、ページZはページXで入力された内容や処理結果、さらにページXのあとに呼び出されたということも知ることはできません。 HTTPにおいては、リクエスト／レスポンスの一往復が完結された処理と見なされるので、次に発生したリクエストはまったく別物と認識されるからです。 しかし、JSP＆サーブレットアプリケーションを構築する場合、複数のページ間で情報の保持が必要になるケースは少なくありません。例えば、認証を必要とするアプリケーションを想定してみてください。トッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
