私のサイトでは簡単なログインフォームがあります。ページはHTTP経由で提供されますが、フォームのPOST URLはHTTPSです。httpsフォームへのPOSTは常に動作しているとは限りません
通常の方法は、ユーザーがユーザー名/パスワードを入力し、フォームが（同じサイトの完全修飾HTTPS URLに）送信された後、POST処理がユーザーのホームページに303リダイレクトされます。しかし時々これは起こらない。
サイクル（これは100％の再現性であるが）これです：
- ログインログインフォーム、詳細を記入して、ログインスクリプトが呼び出されるサーバで
- を提出し、データを検証し、その後、すべてがうまくいけば、ユーザーのホームページに303リダイレクトされます。
- ログアウトをクリックしてからログインをクリックすると、ログインフォームに戻されます
- 私の詳細をもう一度入力して、submitを押してください。
- 今回はログインロジックが実行されません（手順2でログインしたデバッグコードは呼び出されません）。しかし、まだユーザーのホームページにリダイレクトされています。しかし、私は正常にログインしていないので、私はフロントページに追い出される...
なぜ、POSTは常にログインフォームを呼び出さないのですか？私は303がキャッシュされているとは思っていません（それは仕様通りではありません）...
サーバのHTTPSログを見ると、login.phpoが初めて呼び出されていますが二ません....
編集：
OK、我々は問題を解決してきました。興味のある方：
このサイトは、ロードバランサの背後にある2つのWebサーバ上で実行されます。ユーザーセッションは「固定的」です。つまり、ユーザーが1つのWebサーバーをブラウズすると、LBはそのサーバーに「接続」された状態になります。これはクッキーを介して行われます。しかし、いったんHTTPSに切り替えると、ブラウザとWebサーバーの間で接続が暗号化されるため、LBはCookieを読み取ることができません。だから、それはサーバ間で交代していた。 WWeにはWebサーバー間でログイン認証を伝播するコードがありますが、これは十分速くは起こっていませんでした。だから何が起こっていたことだった：サーバAへ
- ユーザーのブラウザ、「Aの上に私を保つ」と言ってクッキーを取得し、自分のログイン資格情報とヒットを埋めるにはHTTPSトラフィックを解読できないこと、
- LBを提出します（したがってクッキー）を送信し、時間の50％をBに送信します。B
- Bはログインを検証し、セッションで認証されるようにユーザーを設定します。
- ホームページは非httpsであれば、LBはクッキーを読み取り、それをAに送ります。これはBから十分に速く伝播していないので、認証の何も知らない...
解決策は、LBがHTTPSトラフィックを復号化できるようにすることで、HTTP/HTTPSの遷移に関係なく、ユーザーが実際に1つのWebサーバーに留まることを保証しました。
コードを投稿することができれば確かに役に立ちます。 – Seb