メモ。
User-AgentがVodafoneとかSoftBankで始まるもの
ページの文字コードに関係なく、utf8にしてURLEncodeにしてsubjectパラメータ、bodyパラメータに設定
User-AgentがJ-PHONE/3.0で始まるもの
Windows-31Jにしてmailbody属性にURLEncodeしたbody部の値を設定
User-AgentがJ-PHONE/4.1/J-SA51で始まるもの
Windows-31Jにしてmailbody属性にURLEncodeしたbody部の値を設定
Windows-31JにしてsubjectパラメータにURLEncodeしたsubject部の値を設定
User-AgentがJ-PHONE/4.1またはJ-PHONE/4.0で始まるもの
Windows-31Jにしてmailbody属性にURLEncodeしたbody部の値を設定
User-Agentが上記以外でJ-PHONEで始まるもの
Windows-31Jにしてmailbody属性にURLEncodeしたbody部の値を設定
Windows-31JにしてsubjectパラメータにURLEncodeしたsubject部の値を設定
User-Agentがさらに上記以外の場合
Windows-31JにしてsubjectパラメータにURLEncodeしたsubject部の値を設定
Windows-31JにしてbodyパラメータにURLEncodeしたbody部の値を設定
・・・であってるかな？
.
2009年3月19日木曜日
[mod_chxj] mailto: v2
登録:
コメントの投稿 (Atom)
54 コメント:
konn様、
とても役立つモジュールの提供、ありがとうございます。
現在、PC・携帯で共通利用できるサイトを構築している、ippsioと申します。
認証用にSunのAccess Managerを利用しようと考えているのですが、
携帯で認証成功後、ログイン成功後の画面（自分サイト内）へリダイレクトする際、
クッキーIDをロストしてしまうのか、うまく遷移しない状況となっています。
原因がよくわかりませんが、リダイレクトするとクッキーIDが毎回入れ替わってしまうようです。
サンプルプログラムを作って動作を確認した所、フォワードならクッキーIDが引き継げていました。
恐れ入りますが、どのようにすればクッキー引継ぎを実現できるか、ご教授頂けたら嬉しいです。
なお、バージョンはmod-chxj_0.12.33 を利用しています。
構成は次のようになっています。
UserAgent：DoCoMo携帯 ＆ FireFox3.0
Ａ：フロントエンドサーバ apache2.2.11 + mod_chxj(Listen: 80, 8080)
Ｂ：コンテンツサーバ Sun Web Server(80)
Ｃ：認証サーバ Sun WebApplication Server(8080)
Ａ，Ｂ，Ｃは全て同じドメイン内のサブドメインとなっています。
①Ａで受け付けた80ポートのアクセスを、バックエンドの80にリバースプロクシします。
②Ｂの80ポートは、未認証と判断すると、UserAgentに認証サーバ（Ｃの8080）へリダイレクト要求します。
③UserAgentはリダイレクト要求を受付け、Ａの8080からＣの8080へリバースプロキシされ、ログイン画面が表示されます。
④UserAgentはＣによって表示されたログイン画面でログインします。
⑤UserAgentが認証成功した後、ＣはUserAgentへ、Ｂのコンテンツへのリダイレクト要求を送信します。
：
⑥ここで本来ならコンテンツが表示されるはずなのですが、再度④のログイン画面が表示されてしまいます。
④の画面ソースを見ると、毎回異なった _chxj_cc の値が設定されているのが確認できます。
お忙しい中、恐れ入りますが、よろしくお願い致します。
投稿ありがとうございます！
レス遅れて申し訳ありません。
まずは、ぱっと見ただけでは思いつきませんので、
いくつか可能性がありそうなところを考えさせてください。
すみません。
よろしくお願いします。
遅れてすみません。
いくつか質問させてください。
まず、ご使用のCookie保存モードは
DBM、MySQL、Memcachedのどれでしょうか？
また、8080の方でSet-Cookieを発行、そしてその際のHost:ヘッダは「ホスト名:8080」となっている、でよいでしょうか？
さらに、上記で保存したCookieを読み込みたいのは80の方で、Host:ヘッダは「ホスト名」となっている、でよいでしょうか？
あと、8080の方で認証後、80の方へリダイレクトする際のContent-Typeはどのようになっていますでしょうか？
すみません・・。
ぜひともよろしくお願いします。
お力添え、本当に感謝します。
＞まず、ご使用のCookie保存モードは
＞DBM、MySQL、Memcachedのどれでしょうか？
利用しているCookie保存モードは、DBMとなります。
設定したフォルダに、Cookie情報がファイル出力されている事は、目視で確認できます。
＞ また、8080の方でSet-Cookieを発行、そしてその際のHost:ヘッダは「ホスト名:8080」となっている、でよいでしょうか？
おっしゃるとおり、8080にて、80へ乗りダイレクト要求を送信する際にSet-Cookieしているようです。
その時のHost:ヘッダは「auth.hoge.net：8080」です。
＞ さらに、上記で保存したCookieを読み込みたいのは80の方で、Host:ヘッダは「ホスト名」となっている、でよいでしょうか？
こちらは。「ocms.hoge.net:80」と、ポート番号が付与されます。
＞あと、8080の方で認証後、80の方へリダイレクトする際のContent-Typeはどのようになっていますでしょうか？
「Content-Type: text/html; charset=Windows-31J」となります。
この時の電文イメージが、下記のようになっています。
(FireFoxのLiveHttpHeaderにて取得）
############################
あるサイト(ocms.hoge.net/ocms/opencms/...へのアクセスに、認証状態を要するため、auth.hoge.net:8080の認証サーバへリダイレクトされる。
80ポートへのアクセスをエージェントがフックし、8080の認証サーバへ。ログイン画面が表示された状態
http://ocms.hoge.net/ocms/opencms/demo_ja/intro.html ← ログイン後画面のURL
GET /ocms/opencms/demo_ja/intro.html HTTP/1.1
Host: ocms.hoge.net
User-Agent: DoCoMo/2.0 P903i(c100;TB;W24H12)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
x-msim-use: on
HTTP/1.x 302 Moved Temporarily
Date: Mon, 30 Mar 2009 17:26:01 GMT
Server: Sun-Java-System-Web-Server/7.0
Content-Length: 2
Location: http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
MyHeader: Hello Joe. It took D=99245 microseconds for Apache to serve this request.
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=Windows-31J
----------------------------------------------------------
http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
GET /amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html HTTP/1.1
Host: auth.hoge.net:8080
User-Agent: DoCoMo/2.0 P903i(c100;TB;W24H12)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
x-msim-use: on
HTTP/1.x 200 OK
Date: Mon, 30 Mar 2009 17:26:01 GMT
Server: Sun Java System Application Server 9.1_02
X-Powered-By: JSP/2.1
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: 7.1 RTM (Fri Feb 9 09:12:44 2007) Linux
AM_CLIENT_TYPE: genericHTML
Content-Type: text/html; charset=Windows-31J
Content-Length: 709
MyHeader: Hello Joe. It took D=37463 microseconds for Apache to serve this request.
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
----------------------------------------------------------
⇒ここで、ログイン画面が表示された状態
↓
ログイン画面でID・PWDを入力し、ログインボタンを押下。その後、認証後画面(ocms.hoge.net:80/ocms/opencms/....)が表示されるはずだが、再度ログイン画面が表示されてしまう。
http://auth.hoge.net:8080/amserver/UI/Login?_chxj_cc=AZOGMW%2F9KsUTnbWvzbn1tA%3D%3D&IDToken1=hogeUser&IDToken2=hogePassword&IDToken3=&IDButton=&goto=aHR0cDovL29jbXMuZ28td2l0aC5uZXQ6ODAvb2Ntcy9vcGVuY21zL2RlbW9famEvaW50cm8uaHRtbA%3D%3D&encoded=true&gx_charset=UTF-8
GET /amserver/UI/Login?_chxj_cc=AZOGMW%2F9KsUTnbWvzbn1tA%3D%3D&IDToken1=hogeUser&IDToken2=hogePassword&IDToken3=&IDButton=&goto=aHR0cDovL29jbXMuZ28td2l0aC5uZXQ6ODAvb2Ntcy9vcGVuY21zL2RlbW9famEvaW50cm8uaHRtbA%3D%3D&encoded=true&gx_charset=UTF-8 HTTP/1.1
Host: auth.hoge.net:8080
User-Agent: DoCoMo/2.0 P903i(c100;TB;W24H12)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
x-msim-use: on
HTTP/1.x 302 Moved Temporarily
Date: Mon, 30 Mar 2009 17:27:11 GMT
Server: Sun Java System Application Server 9.1_02
X-Powered-By: Servlet/2.5
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: 7.1 RTM (Fri Feb 9 09:12:44 2007) Linux
AM_CLIENT_TYPE: genericHTML
X-AuthErrorCode: 0
Content-Type: text/html; charset=Windows-31J
Content-Length: 2
Location: http://ocms.hoge.net:80/ocms/opencms/demo_ja/intro.html ★ ここでCookie_idを引き継げていないために、再度ログイン画面が表示されてしまう？
MyHeader: Hello Joe. It took D=86551 microseconds for Apache to serve this request.
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
----------------------------------------------------------
http://ocms.hoge.net/ocms/opencms/demo_ja/intro.html
GET /ocms/opencms/demo_ja/intro.html HTTP/1.1
Host: ocms.hoge.net:80
User-Agent: DoCoMo/2.0 P903i(c100;TB;W24H12)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
x-msim-use: on
HTTP/1.x 302 Moved Temporarily
Date: Mon, 30 Mar 2009 17:27:11 GMT
Server: Sun-Java-System-Web-Server/7.0
Content-Length: 2
Location: http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
MyHeader: Hello Joe. It took D=14608 microseconds for Apache to serve this request.
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=Windows-31J
----------------------------------------------------------
http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
GET /amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html HTTP/1.1
Host: auth.hoge.net:8080
User-Agent: DoCoMo/2.0 P903i(c100;TB;W24H12)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://auth.hoge.net:8080/amserver/UI/Login?goto=http%3A%2F%2Focms.hoge.net%3A80%2Focms%2Fopencms%2Fdemo_ja%2Fintro.html
x-msim-use: on
HTTP/1.x 200 OK
Date: Mon, 30 Mar 2009 17:27:11 GMT
Server: Sun Java System Application Server 9.1_02
X-Powered-By: JSP/2.1
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: 7.1 RTM (Fri Feb 9 09:12:44 2007) Linux
AM_CLIENT_TYPE: genericHTML
Content-Type: text/html; charset=Windows-31J
Content-Length: 709
MyHeader: Hello Joe. It took D=13599 microseconds for Apache to serve this request.
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
----------------------------------------------------------
⇒ここでまた、ログイン画面が表示された状態・・・・
############################
●複数サーバにするとややこしいので、
単純にTomcatでリダイレクト時のCookieシミュレーションについて動作テストしてみたのですが、
やはり、うまくcookie_idが持ちまわされませんでした。
＃index.jsp のリンクをクリックすると、
＃現在時刻をCookieにセットして、index.jspへリダイレクトするようなサンプル。
お手数をおかけして、大変恐縮ですが、
何卒よろしくお願い致します。
レスありがとうございます。
詳細な情報ありがとうございます！
> ＃index.jsp のリンクをクリックすると、
> ＃現在時刻をCookieにセットして、>index.jspへリダイレクトするようなサンプル。
初歩的なミスのような気がしてきました。
至急調べてみます。
すみません。
よろしくお願いします。
すみません。まだ何もわかっていませんが、こちらで単純にtomcatでリダイレクトした場合のLiveHttpHeaderを張っておきます。
やったことは、
a.jsp -> r_post.jsp/r_get.jsp -> a.jsp
の遷移で、a.jspではCookieを表示するだけです。
r_post.jsp/r_get.jspはそれぞれPOST/GETに対応していて、addCookieしてa.jspにsendRedirectしています。
以下ログです。
http://foo.net/foo/a.jsp?_chxj_cc=MkQDNH2tB2O7jDhxkqAh8A%3D%3D
GET /foo/a.jsp?_chxj_cc=MkQDNH2tB2O7jDhxkqAh8A%3D%3D HTTP/1.1
Host: foo.net
User-Agent: DoCoMo/2.0 P901iTV(c100;TB;W30H15)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
HTTP/1.x 200 OK
Date: Tue, 31 Mar 2009 02:41:30 GMT
Server: Apache-Coyote/1.1
Content-Type: text/html; charset=Windows-31J
Via: 1.1 foo.net
Content-Length: 332
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
----------------------------------------------------------
http://foo.net/foo/r_post.jsp
POST /foo/r_post.jsp HTTP/1.1
Host: foo.net
User-Agent: DoCoMo/2.0 P901iTV(c100;TB;W30H15)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://foo.net/foo/a.jsp?_chxj_cc=MkQDNH2tB2O7jDhxkqAh8A%3D%3D
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
_chxj_cc=egrNKgDkCAVVMwrnQad43g%3D%3D
HTTP/1.x 302 Found
Date: Tue, 31 Mar 2009 02:41:43 GMT
Server: Apache/2.2.3 (Debian) mod_chxj/0.12.33 DAV/2 PHP/5.2.0-8+etch11 mod_ruby/1.2.6 Ruby/1.8.5(2006-08-25) mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: Keep-Alive, Keep-Alive
Keep-Alive: timeout=15, max=99
Via: 1.1 foo.net
Content-Type: text/html; charset=Windows-31J
Content-Length: 2
Location: http://foo.net/foo/a.jsp?_chxj_cc=6%2B3QICLBGT4%2F044A7rsdhQ%3D%3D
----------------------------------------------------------
http://foo.net/foo/a.jsp?_chxj_cc=6%2B3QICLBGT4%2F044A7rsdhQ%3D%3D
GET /foo/a.jsp?_chxj_cc=6%2B3QICLBGT4%2F044A7rsdhQ%3D%3D HTTP/1.1
Host: foo.net
User-Agent: DoCoMo/2.0 P901iTV(c100;TB;W30H15)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://foo.net/foo/a.jsp?_chxj_cc=MkQDNH2tB2O7jDhxkqAh8A%3D%3D
HTTP/1.x 200 OK
Date: Tue, 31 Mar 2009 02:41:43 GMT
Server: Apache-Coyote/1.1
Content-Type: text/html; charset=Windows-31J
Via: 1.1 foo.net
Content-Length: 339
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
----------------------------------------------------------
今のところ以上です。
上記ログはPOSTの場合ですが、GETの場合でも問題ありませんでした。
よろしくお願いします。
たびたびすみません。
わかりました。
mod_chxjでは、セキュリティをちょっとだけ意識して、外部サイトへのリンクまたは外部サイトへのLocationヘッダに
クッキー用パラメータを付加しないようにしています。
外部サイトかどうかは現Hostヘッダとリンクに書かれてあるHostを比較します。
おそらくこれが原因ではないでしょうか？
すみません。
対応策を考えます。
よろしくお願いします。
とりあえず、
http://svn.sourceforge.jp/svnroot/modchxj/branches/RELEASE_0_12_0
の方に対応したものをコミットしました。
こちらでお試しいただけると嬉しいです。
ChxjAllowedCookieDomainというディレクティブを追加しました。
このディレクティブを使用し、
80番、8080番の両方（またはauth.hoge.netとocms.hoge.netの両方）のmod_chxjの設定に
ChxjAllowedCookieDomain hoge.net
と記述していただければ、auth.hoge.netもocms.hoge.netも両方とも_chxj_ccパラメータを付加するようになります。
ChxjAllowedCookieDomainディレクティブが指定されている場合は、Hostヘッダは見に行きません。
すみません。
よろしくお願いします。
迅速なご対応、本当に感謝します。
本日帰宅後にさっそく試してみたいと思います。
少しだけ気がかりなのは、
私が作ったTomcatでのサンプルで、ChxjCookieLazyMode true
なのに、毎回cookie_idが変わってしまうことです。
昨晩、私の作成したサンプルの構成は、
すべて同一ドメイン(test.hoge.net:8080)で
index.jspに設置したリンクをクリックして、CookieTestServletを呼び出し、
Servletクラス内でCookieをセットし、そのServletクラスで
res.sendRedirect("index.jsp"); したり
res.sendRedirect("http://test.hoge.net:8080/コンテキスト名/index.jsp");するものでした。
index.jspではCookie情報を表示しようとするのですが、うまく表示されず、
<a>タグにリライトされるcookie_idは毎回違ったものが設定されていました。。。
私の方でも原因を探ってみようと思います。
（もしかしたら、今回ご対応下さったもので、したいことを全て満たせるかもしれませんが）
素早いご対応、本当に本当に感謝します。どうもありがとうございます。
Tomcatでのサンプル、いままで版で正常動作するようになりました。
取り急ぎ、ご報告まで。
また後ほど
報告させて頂きます。
すみません。ありがとうございます！
一瞬どきっとしました・・。
ありがとうございます。
よろしくお願いします。
とりあえず、現状の版を
0.12.34としてupしました。
よろしくお願いします。
スミマセン、帰宅できませんでした。。
昨晩コメントしたかったのは、次のような事です。
■jspとサーブレットを使ったサンプル
index.jspでSampleRedirectServletへのリンク(相対パス)をクリック →
SampleRedirectServletクラスでクッキーをセットし、sendRedirect("index.jspﾞ)(遷移先の指定は相対パス) →
※このパターンだと、cookie_idは引き継げず、index.jsp ではクッキーの情報を拾えませんでした。
■jspのみを使ったサンプル
index.jspでSampleRedirect.jspへのリンク(相対パス)をクリック →
SampleRedirect.jspでクッキーをセットし、sendRedirect("index.jspﾞ)(遷移先の指定は相対パス) →
※このパターンだと、正常にcookie_idに引き継ぎができ、index.jspにてクッキーの情報が表示できました。
※昨晩、ご報告したのは、こちらのパターンでした。
もしかして、サーブレットのsendRedirect(ﾞ相対パスﾞ)とjspでのsendRedirect(ﾞ相対パスﾞ)したものって、微妙に違うのかな？
もしくは、私のサーブレットの方は、単に古いキャッシュを読んでしまったのかも？
仮説はいくつかありますが、とにかく今日は無事に帰宅して、昨日コミットして頂いたものを試してみたいと思います。
すみません。
せっかくのご投稿、見落としてました。
もしかするとホスト名がlocalhostなのかも
しれません。
また即調べてみます。
よろしくお願いします。
いつも大変お世話になっております。
昨晩、1.2.34版を試しました。
結論から申しあげますと、cookie_idの引継ぎはできるようになりましたが、ログイン画面ループの現象は改善しませんでした。
大変申し訳ありません。
Locationヘッダーに、_chxj_cc のパラメータが２つ付与されてしまっていました。
原因がこれかどうかはわかりませんが、期待動作となりませんでした。
8080の認証サーバに、Cookie付きの電文が届いているか、今日見てみます。
ちなみにLocationヘッダで指定されたURLについて、
１つめの_chxj_ccは
_chxj_cc%3D……%253D%253D
２つめの_chxj_ccは
_chxj_cc=……==
となっておりました。
１つめのパラメータが利用された場合、恐らくうまくCookieの情報をdbmから取得できないと想像します。
== → %3D%3D → %253D%253D と
どんどんURLエンコードされ、うまく元に戻せていないのでは？、と。
レスポンス遅くて申し訳ありません。
以上、宜しくお願いします。
ありがとうございます！
レス遅れて、申し訳ありません。
>Locationヘッダーに、_chxj_cc のパラメータが２つ付与されてしまっていました。
1レスポンスにつき、mod_chxjでの変換が2回動作しているようです。
1レスポンスにつき、mod_chxjが2回動作するような環境でしょうか？
2回動作するはずではないのであれば、バグなので早急に直したいです。
よろしくお願いします。
コンテンツサーバ(80)、及び認証サーバ(8080)にてtcpdumpを取った結果、、、
どうやら、認証を要するコンテンツサーバ(80)へのアクセスの際にCookieの情報が渡っておらず、再度ログイン画面が表示されていました。
tcpdumpを解析した（人がみてわかるようにフォーマットした）電文イメージなど、
現状の動作の様子を記録してみました。
ちょっと量が多いので、人のブログに掲載するには申し訳ないと判断し、Googleサイツへアップロードしました。
恐れ入りますが、ご確認いただければと思います。
http://sites.google.com/site/hogelabo/denbun-imeji
電文イメージとその解説、環境などの事について書いています。
恐れ入りますが、よろしくお願い致します。
すみません。
ありがとうございます！
早速拝見します。
よろしくお願いします。
ありがとうございます！
詳細な情報のため、再現確認できました。ありがとうございます。
原因はChxjConvertRuleの第五引数で
携帯以外のUser-Agentを指定している場合、変換処理が行われない欠陥
でした。
http://sourceforge.jp/ticket/browse.php?group_id=1608&tid=15968
として登録させていただきました。
即修正してみますので、お試しのほど、よろしくお願いいたします。
修正しました。
0.12.35としてアップしてみますので、
お試し願えないでしょうか？
アップは今晩中もしくは明日中には完了するかと思います。
アップが終わりましたらここでご連絡させていただきます。
よろしくお願いいたします。
konn様、お世話になっております。
了解しました。ご連絡お待ちしております。
よろしくお願い致します。
遅くなりました。
ただいま0.12.35としてアップしましたので、お知らせいたします。
こちらでお試しいただけないでしょうか？
よろしくお願いいたします。
いつもお世話になっております。レス遅くなり申し訳ありません。
どうやら、
ブラウザが認証サーバ(8080)からコンテンツサーバ(80)へのリダイレクト要求に応えた際、
コンテンツサーバ(80)へクッキー情報が渡っていないようです。
ただし、ブラウザは_chxj_ccを渡しているのが確認できます。
mod_chxjが、リダイレクト時にクッキー情報をうまく添付できていないような感じでしょうか？
例によって、電文イメージを格納させて頂きました。
す、、すみませんがよろしくお願い致します。
（環境等は前回と特に変わりありません）
http://sites.google.com/site/hogelabo/denbun-imeji-_20090406_night
すみません。
何度もありがとうございます！
>レス遅くなり申し訳ありません。
いえ、全く問題ありません。
>例によって、電文イメージを格納させて頂きました。
ありがとうございます！早速拝見します。
>す、、すみませんがよろしくお願い致します。
何度も本当にすみません・・・。
よろしくお願いいたします。
拝見しました。
>Locationヘッダで指定されたURLを、
>直接アドレスバーに指定してアクセスすると、
>正常にコンテンツサーバ(80)へアクセスできることが確認できました
とのことですが、これは本来正常にコンテンツサーバ(80)へ遷移するはずのところ、認証エラーになり8080へ遷移してしまうが、認証エラーになったLocationヘッダのURL部をコピーしてブラウザからアクセスすると、認証済みとしてアクセスできる、ということでよいでしょうか・・？
申し訳ありませんがmod_chxjのデバッグログをいただけないでしょうか？
デバッグログはLogLevel debugとすればerrorログに出力されると思います。
結構大きなファイルになってしまうと思うのですが、access.logと一緒にいただきたいです。
特に認証直後のLocationヘッダ発行後の一連のリクエスト・レスポンスがほしいです。
申し訳ありません。
もしよければで結構ですので
お手数ですが、よろしくお願いいたします。
すみません。
あと、できましたら、
iモードの実機かauの実機で現状の環境で
やってみてほしいです。
iモードシミュレータでもよいかもしれません。
もし、お手すきであればで結構ですので、
ぜひ、よろしくお願いします。
すみません。
こちらでももう少し環境を似せてみます。
すみません。
konn様。
いつもお世話になっております。
これから試してみます。
結果が出ましたら、また追って報告いたします。
以上、よろしくお願い致します。
konn様、
mod_chxjのデバッグログを添付しました。
格納先は次のURLとなります。
http://sites.google.com/site/hogelabo/mod_chxjdebaggu-rogu
今朝、とりあえずデバッグログが出力されることの確認だけとり、
先ほどきれいに整形しようとおもったのですが、
さっきapacheをリスタートした際、何故かデバッグログが出力されなくなってしまいました。
（というかerror系のログが全く出力されません！？朝は出たのですが）
すみませんが、今朝出力したログだけ添付させてください。
朝はガチャガチャ動かしていただけなので、
もしかしたら何回もログインボタンを押してしまったかもしれないログの内容となっています。
＞ とのことですが、これは本来正常にコンテンツサーバ(80)へ遷移するはずのところ、
＞ 認証エラーになり8080へ遷移してしまうが、認証エラーになったLocationヘッダの
＞ URL部をコピーしてブラウザからアクセスすると、認証済みとしてアクセスできる、と＞ いうことでよいでしょうか・・？
その通りです。
apache＋mod_chxjは、80ポートで受け付けた要求を、コンテンツサーバの80ポート（別サーバ）にプロキシします。
既に認証済みであれば、認証クッキーを持っているのでコンテンツにアクセスできるはずなのですが、
現状、認証クッキーをコンテンツサーバに送れておらず、認証エラーとなってしまいます。
その結果、認証サーバ(8080)へリダイレクトされてしまっているようです。
しかし認証エラーとなったLocationヘッダのURLをブラウザに食わせると、コンテンツサーバ(80)に正常に認証クッキーを渡せるようで、結果認証済みとしてアクセスできました。
今回確認できたデバッグログですが、
chxj_cookie.c:511 failed: chxj_load_cookie_dbm() や、
chxj_cookie.c:320 failed: chxj_save_cookie_dbm() などのログが出力されていることが確認できました。
■認証サーバ(8080)へプロキシする際のログ
access-8080.hoge.net.log
error-8080.hoge.net.log
■コンテンツサーバへプロキシする際のログ
access-ocms.hoge.net.log
error-ocms.hoge.net.log
以上です、昨晩もとんでもない時間まで稼動させてしまい、
申し訳ありません。
書き忘れましたが、
今回に限らず、FireFoxの FireMobileSimulatorを利用して動作確認しています。
利用する携帯電話は P903i を想定した設定を利用しています。
携帯のオプション設定などは特にしておらず、FireMobileSimulatorをダウンロードしたままの状態で動作確認しています。
外出中できちんと内容の精査をしないうちに送信してしまったため、文章に揺らぎがありますね。。。
分かりづらい表現ありましたら、ご指摘ください。
以上です、よろしくお願いします。
ありがとうございます！
拝見しました。
ログを見る限り、
Cannot store Cookie data to DBM file `/usr/local/apache2.2.11/dbm_cookie/cookie.db'
と出ていますので、Cookieですが、DBMに保存できていないようです。
そもそもエラーログに原因を出力していないのも問題ですが、何か書き込めない原因が思いつきますでしょうか？
また、先にご指摘いただいている_chxj_ccパラメータがどんどん増えていく現象も確認できました。ありがとうございます。
こちらについてはあまり問題ではないかと思いますが、見苦しいので直したいと思います。
すみません。よろしくお願いします。
お世話になっております。
やはりデバッグログはうまく出ていないようです。
エラーログは不定期に出ますが、出る条件が特定できないでいます。
関係ないかもしれませんが、Apacheのバージョンを変えて動作を見てみようかと思います(2.2.11→2.2.x)。
あと、思い切ってエラーをprintfに置換してみようかと思います。
以上、宜しくお願いします。
あと、クッキーをDBMに保存できない理由もまだわかっていません。
保存処理を呼び出した結果が、!APR_SUCCESSである事により、クッキーの保存に失敗した旨をログ出力されているようですが、なぜそうなるのか、まだ解析できていません。
以上です、宜しくお願いします。
ありがとうございます！
>保存処理を呼び出した結果が、
>!APR_SUCCESSである事により、
>クッキーの保存に失敗した旨
>をログ出力されているようですが、
>なぜそうなるのか、まだ解析できていません。
すみません・・。
以下お願いがあります。
chxj_dbm.cのint
chxj_save_cookie_dbm関数の中で、
if (retval != APR_SUCCESS) {
のif文が2つあるのですが、2つ目のif文の中のERRマクロを、以下のように置き換えて見てもらえませんでしょうか？
char errstr[256];
ERR(r, "%s:%d Cannot store Cookie data to DBM file `%s' (%d:%s)",
__FILE__,
__LINE__,
chxj_cookie_db_name_create(r, m->cookie_db_dir),
retval,
apr_strerror(retval, errstr, 255));
すみません・・・。
よろしくお願いします。
すみません。可能であれば、で結構です。。
あと、
>エラーログは不定期に出ますが、出る条件が特定できないでいます。
ですが、多分LogLevelがdebugになっていないものと思われます。不定期に出ているものは、エラーだと思われます。
先日拝見したエラーログにはエラーのみが出力されていました。2つのエラーがあって、1つ目は文字コードがおかしい、というエラーで、こちらはChxjConvertRuleで文字コードを指定してやれば解決します。
2つ目はDBMに書き込めない、というエラーで、こちらはエラー情報の出力が足りないので原因が不明です。すみません。
apacheの設定ファイル中のLogLevelを
全てdebugにすれば出ると思います。
grep等でLogLevelという文字列を探してみてください。
実はバグかもしれません。よろしくお願いします。
konn様、
了解しました。試してみます！
しばらくお待ちください。
konn様、
ログを採取しました。
お恥ずかしいですが、LogLevel設定って、既にhttp.confにあったのですね。
debugに設定 ⇒ warnで上書かれてました。
http://sites.google.com/site/hogelabo/mod_chxjdebaggu-rogu-20090410
http://sites.google.com/site/hogelabo/mod_chxjdebaggu-rogu-20090410-1
とりいそぎ、ご報告です。
コンテンツサーバ側で、クッキーのロードに失敗している箇所もあるみたいです。
私も仕事が忙しくなりましたので、レス等ゆっくりで大丈夫です。
（Javaに使うヒープサイジングしてます。）
以上です、よろしくお願いします。
ありがとうございます！
早速拝見します。
よろしくお願いします。
すみません。
拝見しました。
見つけてしまいました。
せっかくDBMに保存しているのにもかかわらず、HostヘッダにPort番号が付加されているため、送信すべきCookieとして判断していなかったのが原因のようです。
つまりHostヘッダのPort番号をはずして処理すべきところを、そのように処理していなかった欠陥でした。
これとは別にload時のエラーも出ていますが、これは該当Cookieが無かったためで、あえてエラーとしてログに出す必要が無いのに出しているという欠陥です。
あと、気になるところとしては先日いただいたログに出ていたCookie保存時のエラーですが、今回いただいたログには出ていないようです。
次の版でこの辺のエラーログをちゃんとしますので、お手すきのときにでも、お試しいただければ助かります。
修正しましたら、ご連絡差し上げます。
>（Javaに使うヒープサイジングしてます。）
ピーク時にフルGCかかりまくりな感じが大好きなのですが、誰も同意してくれません・・・。
申し訳ありません。
よろしくお願いします。
konn様、
ログ解析、どうもありがとうございます。
クッキーの取り扱いって、スクラッチで開発しようと思うと難しいもんですね。
１ヶ月位前は、自分でServletFilterか何かで作ろうと思っていたのですが、、、自分だったら断念してるかもです。
これから、クッキー保存に失敗した場合のログ採取にトライします。採取できましたら、またご報告させて頂きます。
Javaのサイジングはワケわからないです。
WebAPとかミドルが色々絡んでくると、『サイジングできません』って納得してもうらうためにサイジング資料作ってるようなものですし。
ピーク時のFullGCはよく分かります（笑）。あの頑張ってる感がいいです。たまに、対向サーバ側がFullGCで性能が落ちて、こっち側のサーバのCPUにゆとりが出たりすると、『対向サーバ、余計なことしないでよ』と、なんだか腹立ちます。
konn様、
次のURLにログを格納しましたので、
ご確認よろしくお願い致します。
今回のログは、dbmに情報が格納できなくなる状況のログです。
http://sites.google.com/site/hogelabo/mode_chxjdebaggu-rogu-20090411_1
（いつもお願いばかりで申し訳ありません）
どうも、chxj_ccのクエリが長くなると、dbmに保存できなくなるような気がします。
今回だと、ログイン画面⇒ログインボタン押下⇒ログイン画面⇒・・・を繰り返すうちにGET電文が長くなり、そのうちdbmに保存できなくなってるような気がします。
すみませんが、よろしくお願い致します。
ありがとうございます！
ログの方早速拝見します。
>クッキーの取り扱いって、スクラッチ
>で開発しようと思うと難しいもんですね。
いえ、そんなことは無いと思います。
私がへっぽこだったというだけではないでしょうか・・。
>１ヶ月位前は、自分でServletFilter
>か何かで作ろうと思っていたのですが、、、
>自分だったら断念してるかもです。
いえ、そんなことは無いと思います。
私がへっぽこだったというだけではないでしょうか・・・・。
>WebAPとかミドルが色々絡んでくると、
>『サイジングできません』って納得し
>てもうらうためにサイジング資料作っ
>てるようなものですし。
わかります。。とてもわかります。。
いつも、GCが便利なんだか不便なんだかわからなくなる時ですよね・・。
>どうも、chxj_ccのクエリが長くなると、dbmに保存できなくなるような気がします。
>今回だと、ログイン画面⇒ログインボタン押下⇒ログイン画面⇒・・・
>を繰り返すうちにGET電文が長くなり、そのうちdbmに保存できなくな
>ってるような気がします。
そもそも_chxj_ccをどんどんつけていくのがいけないのですが、
多分ですが、libaprutilのdbmはSDBMを使用しているためだと思われます。
SDBMではキーと値あわせて1008byteまでらしく、エラーになってしまいます。
SDBMだとさらにハッシュ値が重なってもエラーになってしまいます。
SDBMを無効にして、GDBMを使用するようlibaprutilをコンパイルしておけば問題ないのですが・・・。
ということで、いったんリリースした後、mod_chxjで直接gdbmを使うよう修正しようと思います。
まずは今晩、_chxj_ccが複数回付かないよう修正したものをアップしようと思っていますので、
よろしくお願いします。
遅くなってすみません。
ただいま、0.12.36としてアップしました。
おそらくこれで、普通にログインできるのではないかと思います。
お試しいただけると助かります。
また、保存できなくなる件ですが、
これからGDBMを直接リンクするよう修正しますので、よろしくお願いします。
申し訳ありません。
よろしくお願いいたします。
konn様、
レス遅くなり申し訳ありません。
本日動作確認し、まずは無事にログイン後画面に遷移することができました。
丁寧なご対応、どうもありがとうございました！感謝します。
ただ・・・、
なぜか特定の条件で、ログイン画面に戻されてしまうパターンがあります（ごめんなさい）
あまり時間が割けず、その時の電文等を確認できていないので、まずはこちらで一次解析をしてみます。
【今回実現できたこと】
・ログイン後画面に正常遷移できたこと。
・上記に続き、認証状態を要するアクセス先に遷移できたこと
【いま出ている問題】
・ある特定のリンクをクリックした際、ログイン画面に戻されてしまうこと。
（そのリンクをクリックした時にどういう遷移方法を取っているのか、未確認です。Forward? Redirect? なんか特別なのか???）
以上です。
PS：
サイジング終わりました。わけわかんないヒープのグラフになりました。
Jmeterによる負荷かけ中･･･380MB
負荷終了後、10分経過すると･･･250MB
そのまま６時間放置すると･･･95MB
というわけで、サイジング不能（笑）
いつもありがとうございます。
>あまり時間が割けず、その時の電文等を確認できていないので、まずはこちらで一次解析をしてみます。
すみません・・。ぜひ、よろしくお願いします。
>というわけで、サイジング不能（笑）
素敵です！
サイジングの目的がわからないので、
的外れかもしれませんが、ふと思いました。
>Jmeterによる負荷かけ中･･･380MB
この値でよいのではないでしょうか・・？
あとは、なんたら部となんでしたっけ部にうまくわけられればFullGCはある程度は抑えられるような気がします。
って全然違いますね。。
すみませんすみません。。
>>Jmeterによる負荷かけ中･･･380MB
>この値でよいのではないでしょうか・・？
そう。結局そうなんです。
こんな感じで負荷かけたら、こんな結果が出ました、的な結果しか出せないです。
ただただ、応答を返し続けるようなものなら見積もりもできるんですがね。
セッションを溜め込むようなシステムになると、負荷のかけかたによってはFullGC祭りになるし、平和に動かし続けることもできるし。
想定した負荷でサイジングしないと、ただ「一応動きました。以上」で終わっちゃいます。
で、依頼人は、セッション上のユーザ数が何人ならメモリを何MB使うか、とかの計算式を知りたかったみたいですけど、
それが計算できても、Javaが平和に動くだけのメモリ量は計算できませんから。。と。
しぶしぶ納得してくれました。
ちなみに、日立のJVMはFullGCを押さえ込むことができるみたいですね。すごすぎです。
なるほど。
勉強になります！
>ちなみに、日立のJVMはFullGCを押さえ込むことができるみたいですね。すごすぎです。
へぇー。それは知りませんでした。
日立と言えば、MP5600だかMP5800を思い出して、なぜかへこんでしまいます。なぜでしょう・・。
konn様、
いつもお世話になっております。
MP5800って、大型コンピュータですね。
月額１億４，１９６万円よりって（笑）
# http://www.hitachi.co.jp/New/cnews/9705/0513.html
どうも、普通のリダイレクト要求でCookieをロストしているようですね。
http://sites.google.com/site/hogelabo/mod_chxjchousa-20090415
でも一応sendRedirect(target)する際、
targetにリクエストから取得した_chxj_ccの値を付加すれば、逃げることもできますので、大問題ではありません（笑）
以上、ご報告です。
ありがとうございます！
>MP5800って、大型コンピュータですね。
そうです。私の中では日立＝汎用機。。
業界デビュー作が確かMP5600かそれ以前の版かで動くものだったと思います。
JCL書いて、COBOL書いて・・。
>どうも、普通のリダイレクト要求でCookieをロストしているようですね。
ぎゃー！！
すみません！
明日、明後日中には直します！
>でも一応sendRedirect(target)する際、
>targetにリクエストから取得した
>_chxj_ccの値を付加すれば、
>逃げることもできますので、
>大問題ではありません（笑）
すみません！
心強いお言葉、ありがとうございます。
とはいえ、かなりまずい欠陥なので
急ぎで直します。。
すみません。
よろしくお願いします。
すみません。
原因が分かりました。
Servletからのリダイレクトでは、
Content-Typeが設定されないので、
クッキーパラメータが付加されない
ようです。
mod_chxjではContent-Typeをあてに
してしまっているので、それが原因かと
思います。
ためしに、
response.setContentType("text/html");
を事前につけてもらえると動作すると思います。
さて、Locationヘッダがあるときは
Content-Typeを見ないよう修正するべきかと思いますので、対応します。
よろしくお願いします。
すみません。
zip中のプログラムでも確認しました。
やはり
setContentTypeを事前に呼んでやると
問題なく動作しました。
やはり、Content-Typeは見ないようにしますね。。
konn様、
レス遅れてすみません（修羅場から無事、戻ってきました）。
ご対応、どうもありがとうございます。
そういえばzipファイル、をGoogleサイツに登録した時、ちゃんとした説明も書かずに丸投げてしまったなぁ、と反省しています。ｽﾐﾏｾﾝ..。
> response.setContentType("text/html");
やはりコレでしたか。
一見無害そうな人が、実は裏で影響しているのは、プログラムの世界も人間界も同じなのかも・・（笑）
急いでいませんので、お茶でも飲みながらゆっくり修正して下さい。
しかし、jspでのリダイレクトとServletでのリダイレクトが微妙に違う事なんて、今まで知りませんでした。
大変勉強になりました。
さて、当システムの方ですが、
かなり普通に稼動するようになりました。
ここまで短期間で動作させられるようになったのは、konn様のおかげと、ひじょうに感謝しております。
（システム稼動するまでの見積もりより、３ヶ月くらい大幅に短縮できましたし、若干Cも覚えました☆）
現在、サンのWebSerberが勝手にキャッシュを溜め込んじゃう問題と戦ってます。
Sun製品は勝手がわからず、苦戦します。性能はApacheよりも数倍上らしいのですが、、、。設定が便利（ほとんどの設定がGUI）すぎて逆に使いづらいところがあります。
設定ファイルのありかがわからん!!
私のデビュー戦は、単なるDellのPCでした。
コンパイルに５分以上かかるマシンで「ちゃんと納期守れー！」と怒られていました。懐かしい。
今日、明日はすこしのんびりできます☆
すみません！
見逃してました！
>レス遅れてすみません（修羅場から無事、戻ってきました）。
お疲れ様です！
>そういえばzipファイル、をGoogleサイツに登録した時、ちゃんとした説明も書かずに丸投げてしまったなぁ、と反省しています。ｽﾐﾏｾﾝ..。
いえ、問題ありません！
ソースがあるので。
>急いでいませんので、お茶でも飲みながらゆっくり修正して下さい。
すみません。ありがとうございます。。
>しかし、jspでのリダイレクトとServletでのリダイレクトが微妙に違う事なんて、今まで知りませんでした。
大変勉強になりました。
すみません。。私も知りませんでした。。
ひとつ利口になれた気がします。ありがとうございます。
>現在、サンのWebSerberが勝手にキャッシュを溜め込んじゃう問題と戦ってます。
SunはSPARCなSolarisとJavaしか触ったこと無いですね・・。面白そうです。
OpenSSOもSunでしたっけ。
>設定が便利（ほとんどの設定がGUI）すぎて逆に使いづらいところがあります。
すみません。
すごくよくわかりません。
便利なんですけどね。
>konn様のおかげと、ひじょうに感謝しております。
いえ、ippsioさんのおかげと思っています。本当にいろいろとありがとうございます！
まだ2つほどタスクが残っていますが。
（すみません。）
またよろしくお願いします。
コメントを投稿