-------------------------------------------------------------------------
Weberでコネクションプール無しの設定はできないのでしょうか？
（ファイアオールの設定で、コネクションプールの接続が切られて困ってます） 
-------------------------------------------------------------------------
こんにちわ。
単にWeberのコネクションプールを無効にするだけでしたら、
web.xmlの&quot;transactionFilter&quot;を定義しているfilter要素とfilter-mapping
要素をコメントアウトしていただければOKです。
ただし、この場合だとDBへの接続を別途考慮する必要があります。
特にDaoクラスはWeberのコネクションプールを間接的に呼び出していますので、
なんらかの対応が必要になってきます。

たとえばそちらの環境でDataSourceを利用することは可能でしょうか？
Weberでは、srcフォルダ配下にあるdi-config.xmlでDataSourceを指定することができま
す(再コンパイルが必要です)。

（di-config ConnectionManger要素のDataSource設定例）
&lt;bean id=&quot;ConnectionManager&quot; 
    type=&quot;org.itscool.commons.connection.DataSourceConnectionManager&quot; singleton=&quot;true&quot;&gt;
    &lt;property name=&quot;dsName&quot; value=&quot;java:comp/env/登録済みのデータソース名&quot;/&gt;
&lt;/bean&gt;

この場合、元々定義されている&quot;JdbcConnectionManager&quot;の部分は
コメントアウトしておいてください。
こんな回答でよろしかったでしょうか？ご指摘ご質問ございましたらまたご連絡下さい


-------------------------------------------------------------------------
di-configの設定で、複数のログファイルへの出力設定ってできますでしょうか？
weber.logの他に、trace.logを出力するとか。
Weberのバージョンは3.1.2です。 
-------------------------------------------------------------------------
残念ながら、Weber自体には複数のログファイルの出力を制御することは出来ませんが、
例えば、org.itscool.commons.logging.SimpleLogを継承したトレース用のログを
di-config.xmlに登録することにより、Webアプリケーション内で複数ログファイル
へのログ出力を行うことができます。

手順１） SimpleLogログを継承したTraceLogを作成します（シングルトンである必要があります）
<pre>
package org.itscool.commons_ex.logging;

import org.itscool.commons.logging.AbstractLog;
import org.itscool.commons.logging.SimpleLog;

public class TraceLog extends SimpleLog{
    private static TraceLog log = new TraceLog();
    
    /**
     * SimpleLogのgetInstance()をオーバーライドして、
     * トレース用のインスタンスを返しています。
    */
    public static AbstractLog getInstance(){
        return log;
    } 
    
}
</pre>

手順２）TraceLog用の設定をdi-config.xmlに登録します

&lt;!-- ロギングユーティリティ（トレース用） --&gt;
&lt;bean id="TraceLog" type="org.itscool.commons_ex.logging.TraceLog" singleton="true"&gt;
    &lt;property name="level" value="trace"/&gt;
    &lt;property name="maxSize" value="3000"/&gt;
    &lt;property name="logPath" value="C:/trace.log"/&gt;
    &lt;property name="mode" value="all"/&gt;
    &lt;property name="encode" value="Shift_JIS"/&gt;
&lt;/bean&gt;

&lt;!-- ロギングユーティリティ（既存） --&gt;
&lt;bean id="Log" type="org.itscool.commons.logging.SimpleLog" singleton="true"&gt;
    &lt;property name="maxSize" value="3000"/&gt;
    &lt;property name="logPath" value="C:/weber.log"/&gt;
    &lt;property name="level" value="info"/&gt;
    &lt;property name="mode" value="all"/&gt;
    &lt;property name="encode" value="Shift_JIS"/&gt;
&lt;/bean&gt;

手順３）登録したTraceLogをWebアプリケーション内で呼び出します。
    BeanFactory factory = BeanFactory.getInstance();
    //TraceLogインスタンスを取得します
    AbstractLog traceLog = (AbstractLog)factory.getInstance("TraceLog");
    if(!traceLog.isInit()){ //TraceLogが初期化されていない場合
        //TraceLogを初期化します（通常はWebアプリケーション起動時に１回実行するのみでOKです）
        traceLog = (AbstractLog)factory.createInstance("TraceLog");
    }
    //TraceLogを使ったログの制御
    traceLog.trace("trace sample ProjectSwitchAction doExecute");

    //既存のログインスタンスを使ったログの制御
    AbstractLog weberLog = (AbstractLog)factory.getInstance("Log");
    weberLog.trace("weber sample ProjectSwitchAction doExecute");
        
-------------------------------------------------------------------------
１．Java暗号化拡張機能（JCE）による暗号化
-------------------------------------------------------------------------
１．１　概要
　Java言語による暗号の解説を行います。
　JDK5.0には、JCE（Java 暗号化拡張機能）が含まれており、この機能を利用すると、
共通鍵方式による暗号化や公開鍵方式による暗号化機能を実装できます。 

１．２　共通鍵方式（秘密鍵）での暗号化
　Javaでは、共通鍵という言い方をせず、「秘密鍵」（Secret Key）といいます。
本解説では、この表現にしたがって説明します。

また、この表現に従いますと、公開鍵方式の私有鍵に相当する秘密鍵の表現と混同
しますので、「公開鍵」と「私有鍵」という表現に統一し、曖昧にならないようにします。

秘密鍵による暗号化では、パスワードベース暗号化もサポートされていますので
それぞれの方法を解説します。 

１．２．１　暗号化と復号　（自動生成鍵による）
　暗号化する秘密鍵を自動で生成して暗号化するコードを以下に示します。暗号化と復号では、
KeyGeneratorクラスを使って秘密鍵を生成し、Cipherクラスを使って暗号化と復号を行います。
　ここで説明する方法で利用できる既定の暗号化のアルゴリズムは、以下のとおりです。

ＡＥＳ 
ARCFOUR/RC4 
Blowfish 
DES 
DESede 
RC2 
これらの暗号化アルゴリズムは、鍵生成およびCipherの生成の際に指定します。
以下に暗号化と復号のコードを記します。
 
/*
 * 暗号化と復号
 */
import java.security.*;
import javax.crypto.*;
import javax.crypto.spec.IvParameterSpec;


public class Encrypt01 {

    public static void main(String[] args) {

        try {

            // 暗号化
            KeyGenerator kg = KeyGenerator.getInstance("DES");
            Key key = kg.generateKey();
            Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");
            c.init(Cipher.ENCRYPT_MODE, key);
            byte input[] = "To be encrypted data.".getBytes();
            byte encrypted[] = c.doFinal(input); // ここで暗号化

            // ここから復号処理
            byte iv[] = c.getIV();

            IvParameterSpec dps = new IvParameterSpec(iv);
            c.init(Cipher.DECRYPT_MODE, key, dps);
            byte output[] = c.doFinal(encrypted);

            // 表示
            System.out.println("The string was \"");
            System.out.println(new String(output) + "\"");

        } catch (Exception e) {

            e.printStackTrace();

        }
    }
}
 
暗号化では、鍵を生成し、その鍵を使ってデータ（クリアテキストといいます）を暗号化します。
復号の際は、同じ鍵を使って暗号化されたデータを復号します。

鍵の生成
KeyGeneratorクラスを使い鍵（Keyクラス）を生成します。KeyGenaratorクラスのインスタンスは、
コードのようにgetInstance( )を利用します。
この際に先に示したアルゴリズムを指定します。アルゴリズム名は大小文字を区別しません。
指定したアルゴリズム用の鍵は、generateKey( )で生成されます。このメソッドをコールするごと
に新たな鍵が（ランダムに）生成されます。

暗号化準備
暗号化では、Cipherクラスを使いますので、まずインスタンスを生成います。コードにあるように
getInstance( )メソッドを利用します。このとき、引数には暗号化のアルゴリズム（algorithm）
とともにモード（mode）とパディング（padding）方式を以下の形式で指定します。
　　　algorithm/mode/padding
モードおよびパディング方式は省略できますので
　　　algorithm
と指定してもかまいません。省略された場合は、既定の値が適用されます。SunJCEの場合は、
DES、DES-EDE、Blowfish暗号のデフォルトモードは ECBで、パディング方式は PKCS5Paddingです。
そのため、“DES/ECB/PKCS5Padding”と“DES”は同じです。

暗号アルゴリズムとして（既定で）指定できるものは、以下のとおりですが、アルゴリズムによって
具体的な実装方法が異なる場合がありますので注意してください。

AES: Advanced Encryption Standard として、NIST によって FIPS ドラフトに指定された。 
ARCFOUR/RC4: Ron Rivest が開発したストリーム暗号。 
Blowfish: Bruce Schneier 氏の設計によるブロック暗号 
DES: データ暗号化規格 (FIPS PUB 46-2 で定義) 
DESede: トリプル DES 暗号化 (DES-EDE) 
ECIES (Elliptic Curve Integrated Encryption Scheme) 
PBEWith<digest>And<encryption> または PBEWith<prf>And<encryption>: パスワードベース
の暗号アルゴリズム (PKCS #5) で、指定されたメッセージダイジェスト (<digest>) または
擬似暗号関数 (<prf>)、暗号アルゴリズム (<encryption>) を使用する。後ほど用例を示して
説明します。 
RC2、RC4、および RC5: RSA Data Security, Inc の Ron Rivest により開発された可変
キーサイズ暗号化アルゴリズム 
RSA: PKCS #1 で定義されている RSA 暗号化アルゴリズム 
なお、モードおよびパディング方式は以下のような値を指定できます。
モードは、 
NONE: モードなし 
CBC: FIPS PUB 81 で定義された Cipher Block Chaining Mode 
CFB: FIPS PUB 81 で定義された Cipher Feedback Mode 
ECB: 米国商務省 National Institute of Standards and Technology (NIST) の Federal 
Information Processing Standard (FIPS) PUB 81「DES Modes of Operation」
で定義された Electronic Codebook Mode (1980 年 12 月) 
OFB: FIPS PUB 81 で定義された Output Feedback Mode 
PCBC: Kerberos バージョン 4 で定義された Propagating Cipher Block Chaining 
パディング方式は、 
ISO10126Padding: このブロック暗号用パディングは、W3C の「XML Encryption Syntax 
and Processing」ドキュメントに記載されている。 
NoPadding: パディングなし 
OAEPWith<digest>And<mgf>Padding: PKCS #1 に定義されている Optimal Asymmetric
 Encryption Padding スキーマ。 
PKCS5Padding: 「PKCS #5: Password-Based Encryption Standard」バージョン 
1.5 (RSA Laboratories、1993 年 11 月) で規定されたパディング方式 
SSL3Padding: SSL Protocol バージョン 3.0 のセクション 5.2.3.2 (CBC ブロック
暗号) で規定されたパディング方式 
なお、山括弧で囲まれた項目は、その他の名前で置き換えるプレースホルダです。

インスタンスを生成した後は、それを初期化します。init( )メソッドを使い、
暗号化（ENCRYPT_MODE）もしくは、復号（DECRYPT_MODE）の指定とともに生成した
鍵を与えます。

暗号化の実施
初期化された Cipher を使って暗号化を実施します。
バイトデータを引数として Cipher の doFinal( )メソッドに与えれると、
暗号化されたデータを受け取ることができます。

復号の準備
暗号化されたデータを復号するときは、暗号化データとその暗号に利用した鍵が必要
になります。鍵は、暗号化の際に生成したものをそのまま利用します。
また、暗号アルゴリズムが DES、DES-EDE、Blowfish（ただし、モードがCBC、CFB、OFB、
PCBCのとき）の場合は、アルゴリズムパラメータを指定しなければなりません。
アルゴリズムパラメータは、Cipherから取得します。
まず、初期化されたCipherから初期化ベクトルをgetIV( )メソッドで取り出し、
その値を引数にしてアルゴリズムパラメータを取得します。（以下参照）

    byte iv[] = c.getIV();
    IvParameterSpec dps = new IvParameterSpec(iv);
このインスタンスを使って Cipher を初期化します。（以下参照）

    c.init(Cipher.DECRYPT_MODE, key, dps);
この Cipher から doFinal( )メソッドを使って復号されたデータを取得します。

この方法では、暗号化されたデータのほか暗号化の鍵データを復号する側に渡さな
ければなりません。
暗号化の鍵をパスワードのように指定できれば、より用意に暗号化と復号を実施する
ことができます。次では、その方法を記します。 

------------------------------------------------------------------------------
IEが原因でセッション変数が要求間で保持されない
------------------------------------------------------------------------------

あるWebアプリケーションを作っている際に、クッキーをどうしても保存できないという
トラブルに遭遇ししました。

調べていくと、全く同じスクリプトを別ホストに設置すると正常に保存できることが
確認できたので、どうもホスト名に問題がありそうです。

ということで正常にクッキーを保存できるホスト名とできないホスト名を眺めていると、
ある違いに気づきました。

そう、クッキーを保存できないホスト名には"_"（アンダースコア）が含まれていたんです。

アンダースコアってRFCが定めるホスト名のガイドラインに違反している文字列なんですね。
そういえば、このサイトのドメインを取得する際、「hori-uchi.com」にしようか、
「hori_uchi.com」にしようか悩んだんですが、「hori_uchi.com」はドメイン登録できな
かったような記憶がうっすらあります。。 

話をクッキーにもどしますが、IE5.01SP1以降ではRFCに準拠しないホスト名からクッキーは
セキュリティの観点から保存しないようになっているようです。 
こちらに詳しい情報がまとめられています。それによると、 

このIEのセキュリティパッチは、悪意あるWebサイトが他のWebサイトのCookieを取得できる
脆弱性を排除するためのもので、IE5.01SP1以降のリリースのIEリリース、SPに含まれます。

このパッチを適用すると、以下のいずれかに該当する場合、cookieはブラウザに保存されません。 
URLのホスト名が、RFCのドメイン名のガイドラインに違反している文字を含む場合（"_"など






------------------------------------------------------------------------------
[PRB] Internet Explorer セキュリティ修正プログラム MS01-055 のインストール後、
セッション変数が要求間で保持されない
------------------------------------------------------------------------------

対象製品
文書番号 : 316112 
最終更新日 : 2005年7月11日 
リビジョン : 5.2 
現象
Microsoft Internet Explorer 5.5 または 6.0 用のセキュリティ修正プログラム 
MS01-055 のインストール後、次の問題が発生することがあります。 
? セッション変数が失われる。  
? 要求間でセッション状態が維持されない。  
? クライアント システム上で Cookie が設定されない。  
注 : セキュリティ修正プログラム MS01-055 で提供された修正を含む、
より最新の修正プログラムのインストール後も、これらの問題が発生することがあります。 
先頭へ戻る

原因
セキュリティ修正プログラム MS01-055 では、不適切な構文を使用した名前のサーバー
は Cookie 名を設定できません。
Cookie を使用するドメインでは、ドメイン名およびサーバー名に英数字 ("-" または 
".") だけを使用しなければなりません。

サーバー名にアンダースコア ("_") など、その他の文字が含まれている場合、
Internet Explorer は Cookie をブロックします。 

ASP のセッション状態とセッション変数の機能は Cookie に依存しているため、
クライアント上に Cookie を設定できない場合、ASP は要求間でセッション状態を維持
できません。 

この問題は、ホスト ヘッダ内の不適切な名前構文が原因の場合もあります。 
先頭へ戻る

解決方法
この問題を回避するには、次の方法のいずれかを使用します。 ? ドメインとサーバーの
名前をを英数字だけを使用する名前に変更する。  
? ドメイン名やサーバー名ではなく、インターネット プロトコル (IP) アドレスを使用
してサーバーを参照する。  
注 : サーバー名の変更後は、Microsoft IIS (インターネット インフォメーション 
サーバー) 構成の変更が必要になることがあります。詳細は｢関連情報｣を参照してください。 
先頭へ戻る

状況
この動作は仕様です。 
先頭へ戻る

詳細
Internet Explorer 5.5 および 6 には脆弱性が存在します。この脆弱性を利用して、
悪意のあるユーザーが、クライアント コンピュータに格納されている Cookie に対して、
Web サイトから不正にアクセスすることを可能にする URL を作成し、
これらの Cookie に含まれている値を変更する可能性があります。

一部の Web サイトでは、Cookie を使用して重要なデータをクライアント コンピュータ
に格納しているため、このセキュリティの脆弱性により個人情報が漏洩する可能性があります。 

セキュリティ修正プログラム MS01-055 は、不適切構文を使用した名前のサーバーが 
Cookie 名を設定できなくすることにより、セキュリティの脆弱性を修正します。
この修正プログラムでは、サーバー名は RFC (Request for Comments) 833 の Appendix 
、"DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION" で定義されている名前付け
規則に従う必要があります。詳細は｢関連情報｣を参照してください。 
先頭へ戻る
