携帯電話でのセッション管理 - Ceekz Logs (Move to y.ceek.jp)
DB の構造は、上記のようになると思う。 0. session_key の配布を行う （新規セッション開始） 1. session_key と user_agent の照合を行う （失敗時はパスワード認証ページへ） 2. session_key を session_key_prev に移す 3. session_key に新たなキーを配布 4. ページ表示 （ページ内のリンクは 3 の session_key を渡す） アプリケーションの手順は、これで良いかな。 携帯電話は、1ウインドウしか表示できないので、セッションキーを毎回更新しても問題ない。ただし、リンクを辿らずに「戻る」の動作を行った場合、直前のセッションキーをフォローする必要もあり session_key_prev を準備した。実際にフォローを行う際は、アプリケーションの手順中の 1 の照合作業で OR 条件にすれば大丈夫。永遠
memokami :: PHP/Tips/セッション廃棄は気をつけよう
セッション廃棄は気をつけよう Javaと違って、PHPって結構セッション廃棄をちゃんと考えてあげないといけなかったり、 session_destroy() ってコマンドはあるけど、実はセッションファイルを消してくれるだけで、 ちっともインテリジェンスなことをしてくれないわけです。 ためしに session_start(); $_SESSION['hoge'] = 'arakiです。'; session_destroy(); print($_SESSION['hoge']); なんてかくと、何事もなかったように'arakiです'と出てきたり。 結構このワナにはまっているアプリはあるものです。 というわけでセッションを廃棄するときは以下の3つをやる必要があります。 1.メモリ上のセッション情報を消す。 2.ブラウザのクッキーからセッションを消す。 3.セッションファイルを消す。 これ
さくらのレンタルサーバ
レンタルサーバなら「さくらのレンタルサーバ」！ 月額換算でわずか129円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能＆大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
PHPのセッション管理に使う箱選び 4 - Webと何かとその近所
前回からの続き まとめ リクエスト/秒を同じグラフにしてみると、5000〜10000リクエスト(セッション)くらいまでは標準方式やmemcachedが速いけど、それ以上になるとInnoDBの方が高速なのがわかる。 最長待ち時間についても同じで、リクエストが少ない場合の差が無い分InnoDBの安定性が光る！ちなみに数値の差が大きいのでグラフは対数で表示(それでも突き抜けているのがあるけど)。 利用者が少なく、Webサーバが1台*1の場合は標準の方式で運用し、それ以上の規模になった場合はMySQLのInnoDB方式が良いという結論。今回はGCをPHP側で制御したけど、確率で動かすと色々と問題があるのでcronなどで定期実行した方が安心。その場合はMyISAMでも良いかも。 今回は財力の都合でテストしなかったNFSの場合、セッションファイルを保存するディレクトリに階層を作ってWebサーバ側のGC
PHPのセッション管理に使う箱選び 3 - Webと何かとその近所
前回からの続き memcached 使用したmemcachedのバージョンは1.2.1。 クライアントにはPECLのmemcache 1.62を使用。設定は初期値のまま。 GCは1/100の設定だけど、処理自体はmemcached側に任せてPHP側では何もしない。 5000リクエストくらいまでは景気が良いけど、その後どんどん遅くなっている。 最長待ち時間を見ると10000リクエスト以上が明らかにおかしい。abの結果をよく見ると10000リクエスト以上では「Failed requests」が結構ある。 失敗したリクエストの割合を出してみると、3〜5%程度が失敗するみたいだ。ただ、まんべんなく失敗するのではなく失敗する期間というのが存在するようなので、割合を出しても意味は無いような気もする。 失敗した時、PHPは Can't connect to localhost:11211, Cannot
PHPのセッション管理に使う箱選び 2 - Webと何かとその近所
前回からの続き MySQL DBにはMySQL-5.0.27を採用。 MyISAMとInnoDBで比較してみる。MEMORY(HEAP)は試していない。MySQLサーバへはUNIXドメインソケットを使って接続し、毎回接続/切断を行うようにしてみた。GCは1/100のまま。 設定の問題もあるかもしれないけど、リクエスト数が増えるとMyISAMの場合は順調に遅くなってしまう。一方のInnoDBはかなり安定した性能。 MyISAMの場合、DELETEを実行する際にテーブルをロックしてしまうため、レコード数が多い状態で全件走査するDELETEが実行されると、長い時間他のクエリが待たされてしまうのが遅くなる原因ではないかと思う。 最長待ち時間もリクエスト/秒と同じ傾向になっている。ひとつのGCの処理が終わる前に別のGCが起動するという状態が繰り返され、どんどん待ち時間が長くなっているみたい。 設定な
PHPのセッション管理に使う箱選び 1 - Webと何かとその近所
PHPには元々セッション管理の機能が用意されているので、一般的な環境であれば組み込みの関数を呼ぶだけでセッション変数を介して値の保存と取得ができるようになる。 この機能は、内部的にはセッション変数の内容をシリアライズした文字列をファイルに保存し、次のリクエスト時にはファイルの内容をアンシリアライズし変数に展開する方法で実現されている。ファイルはsession.save_pathで設定されたディレクトリ*1下にセッションIDを元にした名前で作られる。 また、セッションが開始される時、session.gc_probability / session.gc_divisorの確率でGCが起動しsession.gc_maxlifetime秒前から更新されていないセッションのファイルが削除され、古いセッションは無効になる。 以上は初期設定でPHPのセッション管理機能を使った場合の動作なのだけど、この方
猛省：PHPのセッション有効期限とGC - KoshigoeBLOG
恥ずかしさのあまり、穴を掘ってでも穴に入りたい気分です。 PHPのセッションは、session.gc_maxlifetimeに従ってGCされますが、このsession.gc_maxlifetimeが適用される範囲がsession.save_pathだという事を見落としていました。session.gc_maxlifetimeを変える場合は知っていなければならない事ですが、どうやら勝手に勘違いして自分に都合の良い解釈をしてしまっていたようです。本当に恥ずかしいです。 注意: 異なる値を session.gc_maxlifetime に指定している 別々のスクリプトがセッションデータの保存場所を共有している場合、 一番小さい設定値に達した時点でデータが消去されます。このような場合には、 お互いに session.save_path を使用します。 注意: デフォルトのファイルに基づくセッションハ
PHPで安全なセッション管理を実現する方法に対する高木さんのコメントへのフォロー - いしなお! (2006-11-20)
_ PHPで安全なセッション管理を実現する方法に対する高木さんのコメントへのフォロー 高木さんのはてなブックマークコメントに、 [セキュリティ][乱数][暗号][PHP][moderate] PHPはセッションID生成にsecureな擬似乱数生成系を使用していないようだ。さすがPHPらしい駄目っぷり。 とあって、そこから人がたくさん来ているらしいんで、ちょっとだけフォロー。PHPのセッションID生成は、 sprintf(buf, "%.15s%ld%ld%0.8f", remote_addr ? remote_addr : "", tv.tv_sec, (long int)tv.tv_usec, php_combined_lcg(TSRMLS_C) * 10); なんて感じで、マイクロ秒単位の現在時刻＋ユーザーのリモートアドレス＋combined-LCG（線形合同法による乱数2つを組み合
PHPで安全なセッション管理を実現する方法
_ 残り容量が数十Mバイトになっていた PCがなんかくそ遅いなーと思ってふと空きディスク容量をみたら、残り数十Mバイトまで減っていた。Folder Size for Windowsで各ディレクトリ単位のディスク使用量をながめてみたところ、 Thunderbirdでimapでアクセスしているアカウントのデータフォルダに、なぜか1GバイトオーバーのINBOXファイルがあった。なにこれ？ 削除したけど別に動作には支障はなし。 puttyのlogが無限に追記されたよ……。数Gバイト。 昔ダウンロードしたCD/DVD-ROMのisoイメージファイルが、そこかしこに消されず残ってたよ。10Gバイトオーバー。 あと、細かいテンポラリディレクトリの中身とか消したら、30Gバイトくらい空いた。そこまでやって久しぶりにデフラグを起動したら、表示が真っ赤（ほとんど全部断片化されている）だったので、最適化実行中。
Do You PHP? - Cookieが使えない端末でのSessionIDについて PHP
Cookieが使えない端末でのセッションIDについて ここにある情報はかなり古くなっており、正しくなくなっている可能性があります。掲載しているサンプルコードiなどは、最新のPHPでは動作しない、もしくは、別途設定・調整が必要になるかも知れません。情報を鵜呑みにせず、あなたの手を動かして、あなたの目で確認してください。 セッションIDの出力には、XSS対策のためstrip_tags関数を通したものを出力することが推奨されています。ただし、HTMLタグの内側にその値が含まれる場合、htmlspecialchars関数を使用する必要があります。 携帯端末など、Cookieが使えない場合でもSessionを使用したい場合があります。この場合、基本的にGETパラメータやHIDDEN等を使ってセッションIDを「持ち回す」必要があります。単純に考えると、以下のようなコード（カウンタのサンプルです）
簡単なショッピングカート - Do You PHP?
ここにある情報はかなり古くなっており、正しくなくなっている可能性があります。掲載しているサンプルコードiなどは、最新のPHPでは動作しない、もしくは、別途設定・調整が必要になるかも知れません。情報を鵜呑みにせず、あなたの手を動かして、あなたの目で確認してください。 セッションIDの出力には、XSS対策のためstrip_tags関数を通したものを出力することが推奨されています。ただし、HTMLタグの内側にその値が含まれる場合、htmlspecialchars関数を使用する必要があります。 これもよくあるネタですよね。今回はPHP4のSession管理機能を使ってカートを保持させています。カートのソース自体は、マニュアルに載っているものを参考にしました。ショッピングカートの基本的な流れはこんな感じと思います。後は、購入処理や購入後のカートを消す等の処理を付ければ、簡単ですが完成ですね（たぶ
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
http://www.glamenv-septzen.net/pukiwiki/index.php?cmd=read&page=PHP%2F%A5%BB%A5%C3%A5%B7%A5%E7%A5%F3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.glamenv-septzen.net/pukiwiki/index.php?PHP%2F%A1%D6%A5%DA%A1%BC%A5%B8%A4%CE%CD%AD%B8%FA%B4%FC%B8%C2%C0%DA%A4%EC%A1%D7%C2%D0%BA%F6
http://www.rcdtokyo.com/pc2m/note/archives/i000770.php
http://www.ecoop.net/memo/2007-06-27-1.html
http://www.machu.jp/posts/20060701/p01/
http://www.itt-web.net/modules/xeblog/?action_xeblog_details=1&blog_id=540