v3で解決されるみたいだけど、取り敢えず今はv2.1を使っているのでメモ。
てか、これはさすがに、ちょい問題あるバグと思う…GlassFish に変えたら DoCoMo のユーザがみんなログイン出来なくなっちゃった…みたいになるわけだから…。
コメント頂きました。v2.1でも修正されているようです。
glassfish 2.1 の asadmin start-domain からの応答が一切返ってこない…。全自動でサーバを立ち上げたい人達(おいらだけ?)の怒りのメモ。
結論から言えば、原因は分かったけど対策があるのかどうかは分からない。
ちなみに、以下はおいらが glassfish の開発コミュニティ宛に出したバグレポート。…今回も中学生レベルの英語で果たして通じるのだろうか…。合言葉は「コードは世界を繋ぐ共通言語」、ほれ!for(int i=0; i<3; i++) you.turn(); you.say("wan!"); …ちなみに
前回は、苦闘しながらも何とか通じた…果たして今回は? …異国の技術者達へ毎度毎度、本当にすみません。
どういうバグかの興味はあるけど、おまえの間違いだらけの英語なんぞ読めるか…という賢明な方々は、追記でまだマシなニホンゴを披露しているのでそちらを参照。
Java EE でのログイン処理について全然知らず、ちょっとはまったのでメモ。
まず、Java EE におけるログイン処理(認証)はどうも Java EE の仕様で標準化されている部分とそうでない部分があるみたい。なので、生真面目に JSR をいくら眺めてても全容は掴めないし、GlassFish や Tomcat のマニュアルと睨めっこしてても片手落ちになる。
どうも、こうした構成になっているのは、認証結果と認証用のインタフェースに関しては共通の枠組みで利用しよう、だけど認証の方法や個人データの扱いはコンテナのメーカ側にまかせよう…と言う事らしい。これによって、Kerberos 認証等の様々な認証に対応出来るっぽい…。
で、メモのため GlassFish のファイルレルムとフォーム認証の組み合わせを例に説明。
まず、Java EE で決められている部分。
- web.xmlの認証に関する部分
-
<security-constraint> <web-resource-collection> <web-resource-name>Authentication of FormAuth</web-resource-name> <url-pattern>/userOnly.jsp</url-pattern> </web-resource-collection> <auth-constraint> <role-name>testers</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>testers</role-name> </security-role> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login_err.html</form-error-page> </form-login-config> </login-config> - ログインページ(login.jsp)の一部
-
<body> <div>login</div> <form method="post" action="j_security_check"> <table> <tr> <td>ID</td> <td> <input type="text" name="j_username"/></td> </tr> <tr> <td>Pass</td> <td><input type="password" name="j_password"/></td> </tr> </table> <input type="submit" value="Login" name="submit"/> <input type="reset" value="Reset" name="reset"/> </form> </body>j_security等のj_で始まる名前はどうも予約されているみたい。
GlassFish 特有の部分
- ユーザとグループの追加
-
GlassFish の管理画面から[セキュリティ]→[レルム]→[file]→[ユーザ管理]
ユーザ(tester)とグループ(testers)を追加
※ 初期設定のままならデフォルトレルムは"file"になっているので上記設定だけで問題なし。(変更している場合は[セキュリティ]画面のデフォルトレルムから変更可能)
※ 上記作業は
asadmin create-file-userからも可能 - グループとロールを結びつける (sun-web.xml)
-
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd"> <sun-web-app error-url=""> <context-root>/web</context-root> <security-role-mapping> <role-name>testers</role-name> <group-name>testers</group-name> </security-role-mapping> </sun-web-app>
ちなみにおいらは最後の作業を忘れてはまった…。グループがロールの別名だと思ってたわけ。…すると"リクエストされたリソースへのアクセスが拒否されました"って403エラー!になるわけですなこれが…。ふぃ〜。
glassfish v3 preludeのインストールで失敗した…他のプログラムのインストールでも似たような事があるかもしれないのでメモ。glassfishをインストーラからインストールし、asadmin start-domain domain1ってな感じで起動すると以下のエラーが…
java.io.IOException: Couldn't get lock for C:\Program Files\glassfishv3-prelude-b28\glassfish\domains\domain1/logs/server.log
あちゃらのサイト(英語)によるとVistaでのみ発生する問題らしい。既にバグは修正されているわけだけど、Vistaでは他のソフトのインストールでも似た問題が発生する可能性がある。
というのは、この問題はVistaのセキュリティ機構がかんでいる。Vistaは"C:\Program Files"や"C:\Program Files(x86)"フォルダが勝手に悪意のあるソフトに書き換えられないようにしているのか、その辺に新しいファイルやフォルダを追加したりしようとすると、それがユーザの意図した動作なのかを訪ねてくる。そのため、どうも先の英語サイトを読むとインストーラが設定をしくじって、そうしたフォルダにアクセス権限のない状態でソフトをインストールしているっぽい(英語苦手なので自信なし…)。そのため、ファイルロックを獲得できない(そもそも権限がない)と言われるんだろう…。(ちなみに、Javaは基本アドバイザリロックだけどWindowsのように強制ロック機構を持つOSならば、その機能を拝借できる。)
そんなこんなで、インストールで似たような問題が起きたソフトはもしかすると、Program Files以外のフォルダにインストール先を切り替える事でこうした問題を乗り切れるかもしれない。glassfishの場合、Javaで動くソフトだったので、"C:\JavaSoft\glassfishv3-prelude"って感じでOK。…とはいえ、Sunのインストーラはデフォルトで"C:"直下を指定する。…それなのに、それを勝手にいじっちゃう男がいたんですよ〜、 な〜にぃ〜!!やっちまったなぁ!!って場合だけお試しあれ。ちなみに…、男は黙って、L i n u x ! ! 男は黙って L i n u x ! !
どうも最近、既存の製品におぃ!と突っ込みたくなるような事ばかりだったんだけど…、今日は逆に感謝したくなる警告を出してもらったのでメモ。というのはJSFの実装のSunのRIなんだけど、メッセージをFacesContextに放り込んだはいいんだけど、JSPやらで出力する際に出力場所書くの忘れてて、結局メッセージの出番無し…というミスをした。すると、なんとメッセージがほったらかしになってますよ〜という旨のログが!以下抜粋
sourceId=j_id_id19:description[severity=(ERROR 2), summary=(j_id_id19:description: 未入力です。), detail=(j_id_id19:description: 未入力です。)];|警告: 1 つ以上の FacesMessage が待ち行列に入れられていますが、まだ表示されていない可能性があります。
おぉぉぉ!ありがたやぁ〜!!ありがたやぁ〜!!おかげさまですぐ気づけたよ。
こういう配慮は本当に助かるんだけど、、、作る側(Sun)としては面倒このうえないと思う。いや、これ一つだったらいいんだけどユーザが凡ミスしそうなところってのは何十箇所とあるはず。おいらみたいな輩が同じ事をしようとすると、エラー処理に埋もれて処理の本筋が見えないプログラムになるかもしれない…。う〜ん、さすがだ。


