.NET TIPS

[ASP.NET]アプリケーション個別の構成ファイルの変更を禁止するには?

山田 祥寛
2004/01/16

 ASP.NETの動作を規定する「構成ファイル」は、「マシン構成ファイル(machine.config)」と「アプリケーション構成ファイル(web.config)」に大別される。machine.configはサーバに1つしか配置できないが、web.configはアプリケーションごと、またはアプリケーション・フォルダ配下のサブフォルダ単位に(フォルダ階層ごとに)配置することができる。

 構成ファイル(web.config)が異なる階層のフォルダに配置されており、それぞれのフォルダにある構成ファイルに同一の項目が設定されている場合には、最下層の構成ファイルの設定が優先的に適用されるようになっている。また、構成ファイルに設定されていない項目でも、より上位の階層に配置された構成ファイルにその項目の設定がある場合には、その上層の構成ファイルから「設定の継承」が行われて適用されるようになっている。

 ASP.NETは、このように「構成ファイルを階層構造的に配置する」ことで、アプリケーション(またはサブフォルダ、ページ)単位の柔軟な設定を可能にすると同時に、設定という行為そのものを簡略化できる。

 しかし、こうした柔軟性はよいことばかりではない。複数のアプリケーションが同居する共有サーバ環境を想定してみよう。例えば、あるアプリケーションの管理者がカスタム・エラーの設定を無効にし、すべてのクライアントでエラー・トレースを見られる状態にしていたとしたらどうだろう。この場合、そのアプリケーションよりも下層にあるアプリケーションのエラー・トレースまでも参照されてしまう可能性がある。つまり、1人のアプリケーション管理者の設定が、サーバ全体(または、すべてのアプリケーション管理者)に影響を及ぼす深刻なセキュリティ・ホールとなる恐れがあるのだ。

 当然これは、アプリケーション管理者だけでなく、サーバ全体を管理する人間にとっても、好ましいことではない。設定を変更したアプリケーションのみならず、ほかのアプリケーション(ということは、同居しているほかのアプリケーション管理者)にも重大な影響を及ぼしたとなれば、それは当然のことながらサーバ管理者の責任でもあるのだ。

 そこでASP.NETでは、下位階層における設定の変更(上書き)を、要素単位で禁止する方法を提供している。例えば、カスタム・エラーに関する設定をアプリケーション単位で変更できないようにしたい場合には、machine.configにおいて以下のような設定を行えばよい。

<section name="customErrors" allowDefinition="MachineOnly"
  type="System.Web.Configuration.CustomErrorsConfigHandler, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
machine.configで要素単位での設定の変更を禁止する方法
カスタム・エラーに関する設定をアプリケーション単位で変更できないようにするには、「allowDefinition="MachineOnly"」(赤字の部分のコード)をmachine.configファイルに追記する。

 <section>要素自体は、machine.configファイルにデフォルトで記述されているはずなので、該当個所を(「<section」などで)検索し、そこで見つかった<section>要素のallowDefinition属性として「MachineOnly」を追記すればよい。

 <section>要素のname属性は、該当する構成要素名に対応する。そして、allowDefinition属性が該当する要素の設定許可レベルを指定するものだ。allowDefinition属性に設定可能な値は以下のとおり。

属性値 概要
Everywhere machine.config、web.configの両方で設定が可能
MachineToApplication machine.configとアプリケーション・ルート直下のweb.configでのみ設定が可能。サブフォルダ、またはページ単位のweb.configでは設定不可
MachineOnly machine.configでのみ設定可能
allowDefinition属性の設定値

 つまり、上記の記述例の場合には、<customErrors>要素の設定をmachine.configに限定する。アプリケーション・ルート、アプリケーション配下のサブフォルダにかかわらず、web.configでは<customErrors>要素を記述することはできない。もしもルールを無視した開発者が、自分のアプリケーションのweb.configに<customErrors>要素を記述してしまった場合でも、ASP.NETが以下のような例外を発生する。

web.configに<customErrors>要素を記述した場合のエラー・ページ
このエラーは、machine.configでしか設定できない<customErrors>要素の設定を、web.configに設定した場合に表示される。

 allowDefinition属性に設定する値には「MachineOnly」以外にも「MachineToApplication」があるが、これは、サーバ管理者がサーバ・レベルの管理だけでなく、アプリケーション・レベルの管理までを行い、アプリケーション配下のコンテンツ作成を個別のアプリケーション開発担当者に委ねている場合に有効だ。例を挙げると、アプリケーション・レベルで共通のHTTPモジュールを設定しているような場合(例えば、アプリケーション独自のロギングを行うようなケースでは)、個別のフォルダ(ページ)レベルでモジュールが無効化されてしまうと、アプリケーション全体として正しいログ収集を望むことができなくなってしまう。ここで、allowDefinition属性に「MachineToApplication」を設定しておくと、このような事態を回避することができるようになる。

 構成ファイルにおけるallowDefinition属性の設定の大部分は、デフォルト値の「Everywhere(どこでも可能)」であるが、一部の構成要素については、machine.configであらかじめ制限されているので、注意が必要だ。デフォルトで「Everywhere」以外が指定されている要素について、以下の表にまとめておく。

設定値 対応する要素
MachineOnly <processModel>
MachineToApplication <authorization>、<machineKey>、<securityPolicy>、
<sessionState>、<trust>
デフォルトで設定制限のある主な要素

 なお、allowDefinition属性はサーバ共通のmachine.configでのみ使用が可能であるが、<location>要素のallowOverriide属性を使えば、web.configでもサブフォルダで構成を変更(上書き)されるのを防ぐことができる。これは、サーバ管理権限を持たないアプリケーション管理者が配下のサブフォルダの振り分けのみを行い(例えば、部門ごとに振り分けるなど)、サブフォルダ内のコンテンツについては関与しないというケースに利用することができる。このようなケースで利用すれば、アプリケーション配下のサブフォルダのコンテンツ管理者が、アプリケーション全体の構成を勝手に変更(上書き)するのを禁止できる。

<configuration>
  <location allowOverride="false">
    <system.web>
      <!--サブフォルダでの設定上書きを禁止したい構成要素を記述-->
    </system.web>
  </location>
</configuration>
web.configで要素単位での設定の変更を禁止する方法
サブフォルダでの設定上書きを禁止するには、「allowOverride="false"」(赤字の部分のコード)をweb.configファイルに追記する。

 <location>要素のallowOverride属性をfalseに設定した場合、ここで設定した構成要素を、フォルダ配下のサブフォルダにあるweb.configの構成要素で変更(上書き)することはできない。End of Article

カテゴリ:Webフォーム 処理対象:構成ファイル
使用キーワード:<section>要素、allowDefinition属性
使用キーワード:<location>要素、allowOverride属性
 
この記事と関連性の高い別の.NET TIPS
[ASP.NET]特定のサービスを無効にするには?
アプリケーション設定を活用するには?
Windowsフォームで構成ファイルによりプロパティ値を設定するには?
[ASP.NET]構成ファイルにカスタムの設定項目を追加するには?
常に管理者としてアプリケーションを実行させるには?
このリストは、(株)デジタルアドバンテージが開発した
自動関連記事探索システム Jigsaw(ジグソー) により自動抽出したものです。
generated by

「.NET TIPS」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間