1

私は、webrole が IIS で複数の Web サイトをホストし、ストレージ アカウントの構成によって動的に展開するセットアップを行っています。

IIS で実行されているサードパーティ サイトがあり、これらは RoleEnviroment からの展開設定にアクセスできません。Azure で RoleEnviroment を使用できないように、IIS サイトへのアクセスを制限する方法はありますか?

少し更新:

構成ファイルから重要な設定を移動すると、うまくいく可能性があります。しかし、どうですか <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=c1azuretests;..." />

代わりに実行時に設定することはできません。これは、サードパーティのサイトでも見つけることができないものであるためです。

4

1 に答える 1

0

面白くてスマートなアプローチ。RoleEnvironment へのアクセスを直接制限する方法はありませんが、いくつかの回避策があります。

  • サードパーティのアセンブリでサニティ チェック/スキャンを実行し、RoleEnvironment を参照/使用している場合は実行を拒否します (私のお気に入りではありませんが、実行可能なソリューションです)。
  • 構成設定を Cloud Settings ファイルから Azure Storage Table に移動します (私はこちらの方が好みです)。これで、潜在的な攻撃者はロール名と構成にアクセスできますが、設定にはアクセスできません。

どちらのアプローチにも長所と短所がありますが、私は 2 番目のアプローチの方が好きです。どちらがより多くのコードを記述する必要があるかは疑問ですが、どちらの場合でも、記述したコードは再利用可能です。そして、2 番目のアプローチの利点はより大きく、より優れています。

アップデート

構成設定ではなく Azure テーブルに構成設定を移動すると言うとき、すべての構成設定を意味します。そのため、ストレージ接続文字列も存在します。また、コードにハード コードする必要はなく、Azure テーブルから読み取ることができます。これには、Azure Table Storage でこれらの設定の監視システムを実装する必要があるなど、その他のわずかな影響もあります。これにより、Table で設定を更新するときに実行中のコードで設定を更新する必要があります。実行中のサービスの構成を変更するときに自動的に行うように。

just deploy a new package with changed setting.また、できるのになぜそうするのかわからないchange settings while service is running without redeploying the whole service package！ここでAPI リファレンスを確認し、ここでガイドを確認してください。

于 2013-06-07T09:34:24.927 に答える