Tomcat仮想ホスト構成後のログイン認証コードの問題
2334 ワード
まず問題の現象を説明して、ローカルテストでjava webサイトを実行して、すべて正常です.しかし、サイトをLinuxサーバに配備すると、ログインに問題があり、検証コードの入力が正しくないことを示すメッセージが表示されます.ログインには認証コードを入力する必要がありますが、認証コードの元の値は先にセッションに格納され、「ログイン」をクリックすると、ユーザーが入力した認証コードと元の値が比較されます.ログを見ると、セッションから認証コードがnullであることがわかります.
最初は本人が慣性的にコードの問題だと思っていたが、いくつかの書き方を変えた後も、このような現象が存在し、サーバーとローカル環境の違いをよく考えて、一つの点をロックした.サーバーのドメイン名はローカルとは異なり、サーバー上のtomcatは仮想ホストを設置し、nginxを使ってドメイン名の逆エージェントをした.ここでは、プロジェクトがsiteExampleであると仮定し、ローカルで実行される場合urlは「hettp://localhost:8080/siteExample」と、Linuxサーバで、フレンドリーなURLを作るために、「http://www.example.com”.
サーバには、tomcatのプロジェクトパブリケーションディレクトリ/www/appsが指定されています.tomcatのserver.xmlファイルでは、仮想ホストの構成について次のようになります.
上記の構成でContext要素のpath属性を「」に設定したのは、urlの項目名を除去するためであり、urlは「http://www.example.com:8080」を選択し、nginxの逆エージェントを利用してurlのポート番号を除去すればよい.
ドメイン名の違いを考慮して、ログイン送信のリクエストをよく見て、原因を探しました.jspページでは、私たちが書いたリソースにリンクが含まれているアドレスはすべて現在のurlのアドレスに対しているはずですが、フロントエンドの人がログイン時に送信したリクエストurlは死んでしまい、「/siteExample/login.do」と書かれています.サーバ上で実行されている場合、リクエストの絶対urlは「http://www.example.com/siteExample/login.do」と、最終的に正しいurlは“http://www.example.com/login.do」.検証コードの元の値が存在します.http://www.example.com」のセッションセッションセッションで、ログイン要求時に取得したセッションセッションセッションは「http://www.example.com/siteExample」のように、検証コードの元の値は自然に得られません.
2つの異なるドメイン名は、同じ物理的位置のwebプロジェクトを指しているが、2つの異なるセッションが発生していることがわかる.興味があればtomcatの動作原理を検討することができる.
最初は本人が慣性的にコードの問題だと思っていたが、いくつかの書き方を変えた後も、このような現象が存在し、サーバーとローカル環境の違いをよく考えて、一つの点をロックした.サーバーのドメイン名はローカルとは異なり、サーバー上のtomcatは仮想ホストを設置し、nginxを使ってドメイン名の逆エージェントをした.ここでは、プロジェクトがsiteExampleであると仮定し、ローカルで実行される場合urlは「hettp://localhost:8080/siteExample」と、Linuxサーバで、フレンドリーなURLを作るために、「http://www.example.com”.
サーバには、tomcatのプロジェクトパブリケーションディレクトリ/www/appsが指定されています.tomcatのserver.xmlファイルでは、仮想ホストの構成について次のようになります.
<Host appBase="/www/apps" autoDeploy="true" name="www.example.com" unpackWARs="true">
<Context docBase="/www/apps/siteExample" path="" />
</Host>上記の構成でContext要素のpath属性を「」に設定したのは、urlの項目名を除去するためであり、urlは「http://www.example.com:8080」を選択し、nginxの逆エージェントを利用してurlのポート番号を除去すればよい.
ドメイン名の違いを考慮して、ログイン送信のリクエストをよく見て、原因を探しました.jspページでは、私たちが書いたリソースにリンクが含まれているアドレスはすべて現在のurlのアドレスに対しているはずですが、フロントエンドの人がログイン時に送信したリクエストurlは死んでしまい、「/siteExample/login.do」と書かれています.サーバ上で実行されている場合、リクエストの絶対urlは「http://www.example.com/siteExample/login.do」と、最終的に正しいurlは“http://www.example.com/login.do」.検証コードの元の値が存在します.http://www.example.com」のセッションセッションセッションで、ログイン要求時に取得したセッションセッションセッションは「http://www.example.com/siteExample」のように、検証コードの元の値は自然に得られません.
2つの異なるドメイン名は、同じ物理的位置のwebプロジェクトを指しているが、2つの異なるセッションが発生していることがわかる.興味があればtomcatの動作原理を検討することができる.