ブラウザーで JavaScript から Scripting.Filesystemobject を使用すると、大きなセキュリティ ホールになることはわかっています。MS が最新バージョンの Office でこの穴を塞いでいるという噂を聞きました。これは、XML ファイルの書き出しや音声ファイルの移動など、Scripting.Filesystem オブジェクトへのアクセスに依存するいくつかの重要な機能を備えた、私が取り組んでいるエンタープライズ Web アプリにとっては悪いニュースです。
私は試しましたが、これに関する「ハード」ドキュメントを見つけることができませんでした.私のローカル開発ボックスはこの動作を示しますが、ここの他のマシン(IE以外の最新バージョンはありません)は動作を示しません. これを確認するドキュメントや、activeX コントロールの作成を伴わない回避策を誰かが教えてくれれば、とても感謝しています。
ありがとうございました！
この記事kb240797では、IE のキル ビットについて説明しています。レジストリには、次のキーがあります:-
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX 互換性
その下に一連の CLSID があります (FileSystemObject の CLSID は {0D43FE01-F093-11CF-8940-00A0C9054228} です)。「互換性フラグ」の値にビット 1024 (0x400) がオン (キル ビット) になっている場合、activex コンポーネントはブロックされています。
また、MS が FileSystemObject を停止している、または停止しようとしていると聞いたことがありますが、これを公式に確認したことはなく、現在のシステムには当てはまりません。ただし、キルビットをいじっても役に立たないような方法で内部的にブロックしている可能性があります。
これが役立つかどうかはわかりませんが、廃止されたという話は聞いたことがありFileSystemObjectません。これについてのあなたの情報源を見てみたいです。注意すべきもう 1 つのことは、セキュリティ リスクのために廃止された最後の "主要な" ActiveX コントロールは CAPICOM でしたが、これは Vista のリリースで発表され、最終的に Windows 7 で削除されました。ドキュメントもこの廃止を反映するように変更され、代替案を事前に提案します。
多くの(多くの!) シェル スクリプトはファイル操作に依存しているFileSystemObjectため、代替手段が提供されなければ非推奨になるとは信じがたいと思います。違いが生じる場合FileSystemObjectは、IE エンジンで実行される Windows デスクトップ ガジェットから引き続きアクセスできます。
合法的または違法な理由で、ブラウザーを介してユーザーのファイルシステムにアクセスすることはありません。
ローカル ストレージにアクセスする最良の例は、Google Gears などのシステムを介して行われます。これらのシステムでさえ、Web/シン クライアントの純粋主義者によってしばしば反対されます。