3

ユーザーがREST Webサービスを介してアップロードされたファイルを保存できるようにするコンテンツ管理システムがあります。これらのファイルはリポジトリに保存する前に、その内容が暗号化されます。

これらのファイルを取得すると、ファイルの内容が復号化され、バイト配列に配置されます。その意図は、これらのコンテンツを、クライアントがローカル マシンに保存できる添付ファイルとしてクライアントに返すことです。

これを行うために、現在、コンテンツを一時ファイルに保存し、一時ファイルを添付ファイルとして渡しています。このアプローチには、以前に暗号化されたリポジトリ ファイルが一時ディレクトリに「平文で」保存されるという厄介な副作用がありました。

JVM の終了時に一時ファイルを自動削除するように設定できることはわかっていますが、これはサーバーであるため、サーバーの再起動には長い時間がかかる場合があります。

また、一時ディレクトリを定期的にチェックし、特定の年齢を過ぎたファイルを削除するためのある種のリスナージョブを設定することもできますが、それは面倒なようで、実際には問題を解決しません-露出時間を短縮するだけです.

一時ファイルを回避するための代替手段を探していますが、ユーザーが Web サービスを介して添付ファイルとして (できればメモリ内の) ファイルをダウンロードできるようにします。

何か案が？

ありがとう！

4

5 に答える 5

2

HashMap などの Java オブジェクトにデータを格納し、それをキャッシュとして使用できると思います (ガベージ コレクターがこれを行うことを決定した場合にキャッシュがガベージ コレクションされるように、弱い参照を使用します)。これが使用中のヒープの量に悲惨な結果をもたらすことを意味する場合は、memcache を実行するか、JVM ヒープから離れた場所にオブジェクトを格納するために ehcache などの Java の同等物を検討することができます。

結果をストリーミングして、終了時に JVM によってクリーンアップされるようにすることができない理由はありますか?

于 2011-06-16T15:24:22.733 に答える
2

Streamオプションですか？欠点は、すべてをメモリに保存することです。

于 2011-06-16T15:20:43.850 に答える
1

File オブジェクトを返さなければならない理由はありますか、それとも変更できるものですか?

私が尋ねる理由は、などのいくつかのメソッドを持つインターフェイスを作成しgetName()、getContentStream()具体的な File オブジェクトの代わりにそれを返すことができるからです。

于 2011-06-16T15:22:29.473 に答える
0

ファイルの代わりに調べることができるのは、Memcachedであり、復号化が完了したらファイルを削除します。

また、暗号化されたファイルをblobとしてdbに保存し、ストリームとして取得することもできます。そうすれば、その場で復号化できるはずです。

于 2011-06-16T15:27:50.750 に答える
0

クリアな一時ファイルへの参照を保持し、暗号化が完了したらすぐに削除することはできませんか？おそらく、これを取り巻くプロセスの多くを、ファイル作成を行っているものとして説明しますか？

于 2011-06-16T15:29:05.523 に答える