[upki-fed:00740] Re: uApproveの挙動について

[Hideki SAKAMOTO <xxxxxxx@xxxxxxxx>]

TSNRの坂元です。

やや後ろ向きながら解決いたしましたので報告します。

結論から申しますと、MySQL 5.5ではuApprove.jpがうまく動かないということの
ようでした。

その後、環境の方も疑ってCentOS 5.10とOracleのjdk-6u33という組み合わせで
試したのですが、やはり駄目でした。そこで、CentOSの環境でMySQLを5.0.95に
バージョンダウンした所、同じ設定で不具合がすべて解消されて正常に動くよう
になりました。また、MySQL 5.1.70でも正常に動き、さらにIdPを2.4.0に上げて
も大丈夫なようでした。ちなみに、PostgreSQL(9.2)でも試してみましたが、次の
例外が必ず発生して、こちらは動きませんでした。
-----
java.lang.NullPointerException
        at ch.SWITCH.aai.uApprove.storage.LogInfoJdbc.getData(LogInfoJdbc.java:741)
        at ch.SWITCH.aai.uApprove.viewer.Controller.doPost(Controller.java:211)
-----

MySQLの5.0はすでにEoLを迎えており、5.1も今月いっぱいでEoLになるようです
ので微妙なところではあるのですが、当面はそれで凌ごうと思います。もし関
係者の方が見ておられましたら、MySQL 5.5以降でも動くようにしていただけ
ますと有り難いです。

よろしくお願いいたします。

P.S.
PostgreSQL用にSQLコマンドを調整していて気づいたのですが、mysql.commandsの
45行目の
  date_format(araTimeStamp,'%Y-%m-%d %H:%i%s')
という箇所は、
  date_format(araTimeStamp,'%Y-%m-%d %H:%i:%s')
の間違いではないでしょうか？影響としてはログに記録されるタイムスタンプの
フォーマットがおかしくなるぐらいで、クリティカルな部分では無いようですが。


(2013/12/16 18:40), Hideki SAKAMOTO wrote:
> 土屋先生
> 
> TSNRの坂元です。コメントありがとうございます。おかげさまで進展が
> ありました。
> 
> 今回やった事で効果があったと思われる作業をまとめますと、以下の通りです。
> ・ArpUserテーブルからauUserNameが重複しているもので、他のテーブルに紐付け
>   されているデータがないレコードを削除
> ・ArpUserテーブルのauUserNameにUNIQUE属性付加
> ・MySQLのJDBCドライバを5.1.27にアップデート
> 
> 現状でまだ残っている問題は、以下の通りです。
> ・選択した属性情報提供の設定が次回以降ログイン時に無視されることがある
> ・[新] 属性情報提供のリセット機能の挙動不審
> 
> 以下、詳細となります。
> 
>> 症状からすると，uApprove が確認結果などを格納するデータベースがうまく参照
>> できていない可能性が疑わしいように思います．
>>
>> common.properties の storageType と databaseConfig の設定，および
>> storagetType=database の場合は database.properties の設定を確認されてはど
>> うでしょうか．
> 
> はい、データベースはMySQLを使っており、common.propertiesは、
> -----
>   storageType=database
>   databaseConfig=/usr/local/uApprove/conf/database.properties
> -----
> /usr/local/uApprove/conf/database.propertiesは、
> -----
>   sqlCommands=/usr/local/uApprove/conf/mysql.commands
>   driver=com.mysql.jdbc.Driver
>   url=jdbc:mysql://localhost:3306/uApprove
>   user=uApprove
>   password=**********
> -----
> となっており、作成したテーブルにはそれらしいエントリが登録されている所まで
> は確認しておりました。
> 
> ところが、ArpUserテーブルをよくよく確認すると、auUserNameが重複したレコード
> が複数登録されており、そのうちの1つだけに、AttrReleaseApprovalテーブルや
> CheckAlwaysテーブル上に対応するレコードがある状態でした。そこで他のテーブル
> に対応するレコードの無いArpUserテーブル上のレコードを削除した所、
>>> ・同意画面や送信属性の確認画面で無限ループする
>>> （確認画面で送信を押すと同意画面に戻ってしまう）
> と
>>> ・Internal Server Errorとなる
> の２つの現象はいまのところ発生しなくなりました。mysql.commandsを見ますと
> -----
> selIdxUser = select idxArpUser as idxUser from ArpUser where auUserName = '?'
> -----
> となっておりますので、重複登録によりauUserNameからidxArpUserを取得する
> 段階で値が不定になってしまっていたようです。これで一時しのぎはできまし
> たが、そもそもの重複登録をどうにかしないといけないので、とりあえず
>   ALTER TABLE ArpUser ADD UNIQUE (auUserName);
> と、auUserNameをユニーク化してDB側でエラーになるようにして試した所、
> ArpUserテーブルに既にレコードのあるアカウントでは特に問題ないのです
> が、初めてログインする際に重複登録しようとしているようでした。こちら
> は予想される処理の流れからしてDB処理が怪しいと踏んで、JDBCのドライ
> バを5.1.27にバージョンアップしたところ、いまのところ症状は出ず、
> auUserNameにユニーク属性を付けたままでも動くようになりました。
> 
> ここまででだいぶまともに動くようになってきたものの、
>>> ・最初に「毎回確認する」とした設定が無視されて確認の無いままSPに
>>> 飛んでしまう（あるいは逆に確認画面が表示されてしまう）
> という現象はいまだ発生しています。
> またIdPの認証画面で"Reset my attribute release approvals"チェック
> ボックスを表示して設定を変更しようとすると、SPに飛ぶ前に属性の選択画
> 面が２回表示されたり、ブラウザを再起動して再びログインしようとすると、
> 変更した設定が反映されていなかったりといった現象も出ています。皆様の
> IdPではこのリセット機能も問題なく動いていますでしょうか？
> 
> 引き続きなにかお気づきの点がありましたらコメントいただけますと幸いです。
> 
> よろしくお願いいたします。
> 
> (2013/12/16 12:33), TSUCHIYA Masatoshi wrote:
>>>> On Fri, 13 Dec 2013 20:15:07 +0900
>>>> xxxxxxx@xxxxxxxx (Hideki SAKAMOTO) said as follows:
>>
>>> 現在uApprove.jp(2.2.1b)の動作確認をしており、基本的には動いたのですが、
>>> テストを繰り返していると、
>>> ・同意画面や送信属性の確認画面で無限ループする
>>> （確認画面で送信を押すと同意画面に戻ってしまう）
>>> ・最初に「毎回確認する」とした設定が無視されて確認の無いままSPに
>>> 飛んでしまう（あるいは逆に確認画面が表示されてしまう）
>>> ・Internal Server Errorとなる
>>> 等の現象が発生してかなり不安定な状況です。Internal Server Errorが
>>> 発生した際のTomcatのログを末尾に付けます。
>>
>> 症状からすると，uApprove が確認結果などを格納するデータベースがうまく参照
>> できていない可能性が疑わしいように思います．
>>
>> common.properties の storageType と databaseConfig の設定，および
>> storagetType=database の場合は database.properties の設定を確認されてはど
>> うでしょうか．
>>
>