2012-04-19 14 views
3

私はかなり大きなPHPアプリケーションを持っています(数千のユニークなURL、さまざまな役割を持つユーザログインなど)。PHPはセッションタイムアウトをphp.iniの1時間(3600秒)に設定しています。ログインの仕組みは、ユーザーがアプリケーションに正常にログインすると、ユーザー名、実名、役割IDなど、$ _SESSIONに格納されます。すべてのページアクセス(共通コード)で$これらの変数について_SESSIONがチェックされ、存在する場合、ユーザーは要求された場所に移動します。変数が存在しない場合、ユーザーは「ログインしていない」ページにリダイレクトされます。奇妙で迷惑で非常にランダムなセッションタイムアウト

これは過去数年間正常に動作しており、大部分はうまく機能しています。非常にランダムに、セッションは警告や何か他のことなしにタイムアウトしているようです。ログインしたユーザーの場合、これは次のように表示されます。ログインして何かをして次のページに移動し、代わりにログアウトして「未ログイン」ページに戻ります。もちろん、これは非常に面倒です。しかし、この振る舞いがランダムであるため、調査することは非常に困難です。

どのブラウザでも自分のマシンでこれを体験することはありません。オフィスには別のマシンがあり、これは常にすべてのブラウザで発生します(少なくとも私は問題を再現できます)。さらに別のマシンでは、あるブラウザで発生し、別のブラウザでは発生しません。それでも、別のマシンでは、それは時々起こり、それ以外の時は起こりません。今日、この問題を経験したクライアントから電話がありましたが、別のブラウザで試してみるとうまくいきました。

これは一部のマシンで動作し、同じバージョンの他のマシンでは動作しないため、ブラウザのバージョンによるものではありません。さらに、同じように設定された2台のマシンを持つと、あるマシンでは発生することもありますが、別のマシンでは起こらないことがあります。だから全体的には、セッションでは非常に奇妙なことが起こっているように見えますが、どこを見なければならないのかはまったく分かりません。私はこの数ヶ月のうちのより良い部分についてこれを調査しようとしてきましたが、どこにも得られませんでした。どこを見るか?

この時点では、どんな助力も大変感謝しています。

を追加しました:ここには私のphp.iniのセッション一部です:

[Session] 
session.save_handler = files 
session.use_cookies = 1 
session.name = PHPSESSID 
session.auto_start = 0 
session.cookie_lifetime = 0 
session.cookie_path =/
session.cookie_domain = 
session.cookie_httponly = 
session.serialize_handler = php 
session.gc_divisor  = 100 
session.gc_maxlifetime = 3600 
session.bug_compat_42 = 1 
session.bug_compat_warn = 1 
session.referer_check = 
session.entropy_length = 0 
session.entropy_file = 
session.cache_limiter = nocache 
session.cache_expire = 180 
session.use_trans_sid = 0 
session.hash_function = 0 
session.hash_bits_per_character = 4 
+1

セッションでCookieが使用されていると仮定して、問題を再現するボックスに移動し、[Fiddler](http://fiddler2.com/fiddler2/)のような優れたHTTPプロキシを接続し、間違ったリクエストが異常でないかどうかを確認しますいずれにしても。これは、問題がクライアント側かサーバー側か(あるいはおそらくそれが複数の要因の組み合わせであるかどうか)を示し、場合によってはそれに続く大きなリードを与えます。 – Jon

+0

ところで、これは通常、古いマシンで起こります。いつも問題を多かれ少なかれ見せているオフィスのマシンはいずれも3歳以上です。ほとんどのお客様が政府機関であり、残りの数年後にはハードウェア/ソフトウェア上で動作しているため、ハードウェアのアップグレードを提案しないでください。数ヶ月前にIE6のサポートを止めたとき、私たちは大きな反発を覚えました(大きな顧客を失った)。 –

+0

あなたはどのセッションハンドラを使用していますか? – wgcrouch

答えて

0

私は一貫して、他の上の、そしてないで、いくつかの箱の上にランダムにタイムアウトのセッションで同じ問題を経験していますすべて大部分です多くの試行錯誤の末、コンパクトなプライバシーポリシーの問題を抱えているIEのマシンに戻って問題を追跡しました。私たちは単純にヘッダー( 'P3P:CP =私たちのプライバシーポリシーのためにwww.oururl.tldを訪問してください。')のようなヘッダーを追加しました。これは古いIEからの多くの問題を止めました。これはサードパーティのクッキーにのみ適用されますが、IEを知っている人にのみ適用されます。

第2に、セッションクッキーを.domain.tldに設定した後、www.domain.tldではなくdomain.tldからアクセスするマシンがあることがわかりました。すべてのリクエストがwwwサブドメインに向けられていることを確認して、他のブラウザのほとんどを解決しました。

最後に、私たちのサーバーのタイムゾーンが自動的に設定されたときに問題を引き起こしていたため、セッションタイムアウトをPHPから引き継ぐ必要がありました。私は単純に有効期限を0に設定して、ユーザーがブラウザを閉じるなどして「セッション」が終了するまでブラウザを使用してクッキーをタイムアウトさせないようにします。次に、単純に期限切れの変数をセッションに追加し、手動でチェックして、有効期限に関するすべてのチェックと決定がクライアントではなくサーバーのタイムゾーンで行われるようにしました。

これらの3つの事柄は、GoogleやYahoo Toolbarがブラウザのキャッシュやブラウザの一時インターネットファイルで奇妙なことをしていることが強く疑われる最も再現性のないインスタンスを解決しました。

また、セッションIDの再生成やAJAX /その他の非同期呼び出しを使用している場合は、競合が発生していないことを確認してください。多くの場合、旧式のブラウザでは、IDを再生成するときにクッキーが十分に速く更新されず、新しいブラウザのタイミングでも新しいIDで古いIDを送信してセッションを破棄するだけで十分です。私の最善の解決策は、AJAXのセッションIDを再生成しないことですが、実際のページの読み込み時にのみ、物事が同期したままになるようにしました。古いセッションデータを自動的に削除するのではなく、アプリケーションの必要性だけを判断することができないようにするなど、いくつかの方法があります。

関連する問題