10/03/05 21:05:40 YhhmmRGW0
>>202
>スクリプトからV2C内部を保護するためにそのようにしています。
このような目的の場合、RhinoではClassShutterというJavaクラスへのアクセスをフィルタするセキュリティ機構を利用するのですが、残念ながらScripting API(JSR223)にはセキュリティ機構自体が存在しません。
また、JSR223から固有の実装へは透過的にはなっておらず、実装を素直に取得する方法はありません。
少し詳しく話すと>>199のエラーはバイトコードコンパイルを行っていることに起因します。
この時カスタムクラスローダが必要ですが本質的にはこのセキュリティを制御するにはSecurityControllerを介してドメインごとにクラスローダの作成を行います。
その理由にはjavaのセキュリティ機構でいう特権コードが絡んでいてRhinoのセキュリティとjavaのセキュリティの架け橋をSecurityControllerが担っているからです。
なので根本的解決にはSecurityControllerを利用してセキュリティを実装すべきなのですが、SecurityControllerを利用した方法（createClassLoaderの制限も同様）ではクラスローダそのものが作れないためJavaへの通信そのものに影響を与えてしまいます。
V2Cをスクリプトから守るだけであればClassShutterを使う方法がいいと思います。ですが先述のようにJSR223からは実現不可能です。
ですのでJSR223を用いた実装には潜在的にセキュリティに対する弱さがあり、その対処法も持ち合わせていません。
そこで提案なのですがMozillaのRhinoを直接使い、セキュリティの実装そのものを見直してはいかがでしょうか？
現状の問題点は以下です。
1) JSR223はセキュアではない
2) JSR223でRhinoがサポートされるかは実装依存なのでsunの公式JRE以外ではスクリプトを使うためにMozillaのRhinoが必要
3) JDKのRhinoはバージョンが古く、セキュリティ/バグフィックスが不十分
4)（同上）、言語仕様、LiveConnectが古いので解決できない問題がある
5) 2)などよりMozillaのRhinoを利用する場合JDKのRhinoが互換性を失っているため公開されたスクリプトが動かない可能性がある
6) JDKのRhinoはインタプリタモードで動くので遅い（この際どうでもいい）
MozillaのRhinoを利用した場合これらをまとめて解決可能です。
以上、これらを開発の参考になさってもらえれば幸いです。