ASP.NET アプリケーションとしての Microsoft SharePoint Foundation
最終更新日: 2011年1月28日
適用対象: SharePoint Foundation 2010
この記事の内容
IIS と ASP.NET 構成
要求パイプライン
SharePoint がパイプラインを変更する理由
SharePoint がパイプラインを変更する方法
ここでは、インターネット インフォメーション サービス (IIS) と Microsoft ASP.NET の統合要求パイプラインの変更を基に、Microsoft SharePoint Foundation がどのように構築されているかについて説明します。
注意
このトピックでは、IIS と ASP.NET が統合モードでどのように動作するかについて説明します。この 2 つはクラシック モードでも動作できますが、SharePoint Foundation Web アプリケーションは統合モードを使用するアプリケーション プール内に存在している必要があるため、クラシック モードに関する説明は省きます。
注意
このトピックでは、web.config ファイルと関連ファイルについて述べますが、ファイルのカスタマイズについては述べません。SharePoint Foundation 構成のカスタマイズについては、「Web.config ファイルを使用して作業する」を参照してください。
IIS と ASP.NET 構成
IIS、ASP.NET、Web サイト、アプリケーション、その上に構築されるサービスの構成設定は、構成ファイルの階層内に格納されます。一般原則では、階層内の各ファイルのスコープはその上のファイルよりも限定され、そのスコープ内であれば、階層上位のファイルの設定を上書きできます。さらに、この構成ファイルの 1 つで設定の一部をロックすることもできます。これにより、ロックされた設定を階層下位のファイルが上書きするのを回避します。
階層の最上位は machine.config ファイルで、%WinDir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\ ディレクトリに格納されています。このファイルには、サーバー全体の設定が含まれます。
2 番目のサーバー全体の構成ファイルは、同じディレクトリに格納されているグローバルな web.config ファイルです。
注意
新しいバージョンの ASP.NET がフロントエンド Web サーバーにインストールされている場合でも、SharePoint Foundation 2010 は Microsoft ASP.NET 3.5 を使用します。ただし Version 3.5 では、既定の machine.config ファイルまたはグローバルな web.config ファイルを変更しませんでした。このファイルを変更した直近のバージョンは Microsoft ASP.NET 2.0 です。このような理由から、ファイルは Version 2.0 ブランチの %WinDir%\Microsoft.NET\Framework64\ フォルダーに格納されます。
3 番目のサーバー全体の構成ファイルは IIS 構成ストアの、applicationhost.config ファイルで管理されています。このファイルは、%WinDir%\System32\inetsrv\config\ ディレクトリに格納され、サーバー上の IIS Web サイトとアプリケーション プールの登録、および Web サーバー上のすべての Web アプリケーションに適用されるいくつかの設定を含みます。applicationhost.config の設定は、IIS によって提供されるパイプラインの一部に主として対応します。一方 machine.config とグローバルな web.config ファイルの設定は、ASP.NET によって提供される統合要求パイプラインの一部に主として対応します。
各 IIS Web サイトは、階層上位の構成ファイルから継承された設定をサイト固有の設定で上書きし新しい設定を追加するための、独自の web.config ファイルをルートに持つことができます。
IIS Web サイトの特定の物理ディレクトリまたは仮想ディレクトリも、新しい設定を追加したり継承された設定を上書きするための独自の web.config ファイルを持つことができます。この新しい設定と上書き設定は、当然、ディレクトリおよびそのサブディレクトリ内に格納されたリソースに対する HTTP 要求にのみ適用されます。
注意
SharePoint Foundation 用語の‘Web アプリケーション’は、IIS 用語の‘Web サイト’に密接に関連しています。すべての SharePoint Foundation Web アプリケーションは、同じ名前の IIS Web サイト (通常 1 つのみ) でホストされます (ただし、SharePoint Foundation Web アプリケーションを追加ポートでも使用可能にすることもできます。この場合は、追加の IIS Web サイトでホストされます)。そのため SharePoint Foundation のドキュメントで、Web アプリケーションのルート web.config ファイル、または Web アプリケーションのディレクトリにある web.config ファイルを参照できます。厳密にいえば、実際に参照されているのは、対応する IIS Web サイトのルートとディレクトリです。
これらの構成ファイルによって使用される XML スキーマは、「IIS 7.0: Settings Schema」で説明します。「ASP.NET Configuration Overview」と「The Configuration System in IIS 7.0 (英語)」も参照してください。
要求パイプライン
フロントエンド Web サーバーがクライアントから要求を受け取ると、その要求は要求を処理するユニットのパイプラインを介して渡されます。この処理には、ユーザーの認証、ユーザー権限の確認、応答の作成、応答の送信、要求の記録などがあります。従来、これらのユニットの一部は IIS の旧バージョンで生成され、その他のユニットは ASP.NET で生成されていますが、生成元の違いは SharePoint Foundation にとってほとんど重要ではありません。
HTTP ハンドラー
要求に対する応答は、HTTP ハンドラー オブジェクトによって生成されます。要求は *.config ファイルにより、要求されたリソースと要求内の HTTP 動詞に応じて、HTTP ハンドラー オブジェクト (または HTTP ハンドラー オブジェクトを作成するハンドラー ファクトリ クラス) に割り当てられます。たとえば変更されていない ASP.NET インストールでは、aspx ファイルつまり ASP.NET ページに対する要求が、動詞 "GET" を使用して、要求を処理するための Page オブジェクトを作成する PageHandlerFactory オブジェクトに送信されます。Page クラスのような IHttpHandler クラスを実装するクラスのみが、マネージ コードの HTTP ハンドラーになれます。ハンドラー (またはハンドラー ファクトリ) に対するリソース/動詞ペアのマッピングは、system.webServer 要素の handlers 子要素で指定されます。以下は handlers 要素の例ですが、わかりやすくするために子要素は省略されています。
<location path="" overrideMode="Allow">
<system.webServer>
<handlers accessPolicy="Read, Script">
...
<add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.SimpleHandlerFactory" preCondition="integratedMode" />
<add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
preCondition="integratedMode,runtimeVersionv2.0" />
...
</handlers>
...
</system.webServer>
</location>
location 要素の overrideMode 属性が "Allow" に設定されているため、階層下位の *.config ファイルは、設定を上書きする独自の handler 要素を持つことができます。path 属性が空白文字に設定されているため、これらの設定は、*.config ファイル内で上書きされない限りすべての IIS Web サイトに適用されます。
HTTP モジュール
要求パイプラインには、HTTP モジュールも含まれています。モジュールは、通常 1 つ以上のイベント ハンドラーを含むか、他のモジュールが処理可能な新しいイベントを定義するアセンブリです。HTTP モジュールは、要求のライフサイクルの中で 1 つ以上のイベントを登録できます。このイベントは、多くの場合、要求の前処理または後処理に使用されます。既定のモジュールは、system.webServer 要素の modules 子要素に登録されています。以下は既定の modules 要素です。わかりやすくするために、大部分の子要素は省略されています。
<location path="" overrideMode="Allow">
<system.webServer>
...
<modules>
...
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule"
preCondition="managedHandler" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
...
<add name="RoleManager" type="System.Web.Security.RoleManagerModule"
preCondition="managedHandler" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"
preCondition="managedHandler" />
...
<add name="UrlMappingsModule" type="System.Web.UrlMappingsModule"
preCondition="managedHandler" />
...
</modules>
</system.webServer>
</location>
preCondition 属性では、モジュールが適用される前に、要求が満たさなければならない条件を指定します。属性に "managedHandler" という値が指定されている場合は、モジュールはマネージ リソース (主に aspx ファイルなどの ASP.NET タイプのリソース) に対する要求に適用されます。以下の「SharePoint がパイプラインを変更する方法」では、静的な HTML ファイルなどの ASP.NET タイプでないリソースを含むすべての要求にモジュールが適用されるように、SharePoint Foundation がこの動作を上書きする方法について説明します。HTTP モジュールの詳細については、「Introduction to IIS 7.0 Architecture (英語)」を参照してください。
SharePoint がパイプラインを変更する理由
ここでは、SharePoint Foundation の目的のためにパイプラインの既定の設定を変更しなければならない理由を説明します。
SharePoint Foundation では、ページではなく、リストとリスト アイテムが入力データの主要エンティティである新しい抽象的な Web ワールドが作成されます。当然、少なくともブラウザーを介して入力データの表示と入力データの連携を行うには、なじみのある Web ワールドのブラウザーがレンダリングしたページの最上部にデータが実装されている必要があります。しかしリストは特定のページとは独立して存在し、特定のリストは複数ページに表示される可能性があります。そのため、Web サイトのページ構造によって、多くの用途を持つ SharePoint Foundation の重要性が損なわれました。
Web サイトをページではなくリストを中心に構築することの意味を考えてください。ページの構造を表示するサイト マップは、リストをマップするサイト マップに比べるとあまり興味をひきません。このような理由から、リスト コンテンツのサイト マップは、サイト ページ マップよりはるかに多く使用されます。
ASP.NET リクエスト ハンドラーは、普遍的でないにしろ、通常、要求されたリソースの URL はフロントエンド Web サーバーのファイル システムに直接マップすると想定します。しかし SharePoint Foundation は、カスタマイズされたページなどの多くのリソースをデータベースに格納します。また、ファイルがフロントエンド Web サーバーのファイル システムに格納されている場合でも、SharePoint Foundation は、サーバーの仮想ルート "\" から物理ディレクトリ "inetpub\wwwroot\" への既定の IIS マッピングではなく仮想ディレクトリを広く利用します。その他の理由からも、SharePoint Foundation アプリケーション ページを SharePoint Foundation Web アプリケーション内の各 Web サイトの一部にするために、この技術が必要です。
既定では、FormsAuthentication モジュールなどの ASP.NET によって提供されるパイプライン内のモジュールは、aspx ファイルなどの ASP.NET 関連のリソース タイプのみを処理します。しかし、SharePoint Foundation ドキュメント ライブラリーにはどんなタイプのファイルも格納できます。SharePoint Foundation では、リソースの種類にかかわらず、すべての要求がこれらのモジュールで処理される必要があります。たとえば、SharePoint Foundation ドキュメント ライブラリーの .docx ファイルへのリンクを持つ電子メールをユーザーが受け取った場合、そのユーザーはファイルにアクセスするために認証を受ける必要があります。
既定では、ASP.NET は、aspx ページが初めて要求されるときに、どの aspx ページもメモリにロードされたアセンブリにコンパイルします。SharePoint Foundation の展開では、通常 aspx ページが非常に多いため、これは実用的ではありません。つまりフロントエンド Web サーバーのメモリが抑制され、これらのアセンブリをメモリから動的にアップロードできなくなります。したがって SharePoint Foundation は、大部分の aspx ページを逆コンパイル モードで提供する必要があります。
SharePoint Foundation は、管理の委任を可能にします。サーバーとファームは引き続き IT 担当者によって管理されますが、新しい Web サイト、サイト ページの作成など、従来 IT 専門家や Web サイト デザイナーの作業だと考えられてきた多くのタスクが、SharePoint Foundation では、IT 専門家の観点からすると素人と考えられるユーザーによって処理されます。専門家でないユーザーに権限を委任する場合は、より複雑なパターンの信頼とアクセス許可の管理が必要になります。
ASP.NET の設計では、通常、追加するための管理者権限を持つユーザーのみによって、新しい aspx ページが Web サイトに追加されることを前提としています。したがって、アプリケーションはそのようなページのすべてのコントロールを信頼します。ただし SharePoint Foundation では、より広範囲のエンド ユーザーが aspx ページを追加することを許可しています。ページの追加とカスタマイズアクセス権を持つユーザーであれば、ページの追加ができます。これを実現するには、SharePoint Foundation に、ページで許可されるコントロールを管理者が制限できるようにするシステムが必要です。さらに、ユーザーが作成したページには Web パーツが含まれる可能性があるため、管理者は Web パーツと Web コントロールの数を制限できる必要があります。また、無効なコードにより Web サーバーが停止しないように、どのようなコードを実行できるかについて、ユーザーが追加したコントロールと Web パーツを制限することも必要です。SharePoint は、これらのコントロールを、セーフ モードと呼ばれる制限された実行モードで実行することで、この制限を行います。
SharePoint Foundation は、クライアント コンピューターにインストールされたアセンブリ内のクライアント オブジェクト モデルを公開します。このアセンブリによって、コードがサーバーに送信されバッチ モードで実行されます。これにはサーバー上のホストがバッチを処理する必要があります。このように、ASP.NET には何も組み込まれていません。クライアント側のアセンブリもありません。
SharePoint Foundation はワークフローをサポートし、Windows Workflow Foundation にしっかりと統合されています。
SharePoint Foundation には, .aspx ファイルと .ascx ファイル内で参照されるグローバル化されたリソースの大規模なシステムがあります。リソースには、専門の式ビルダーが必要です。
AJAX の ASP.NET サポートは、Microsoft ASP.NET 3.5 に対応するために一部再設計され、SharePoint Foundation は、カスタム ハンドラーがある新しいデザインをサポートします。
SharePoint Foundation には、サーバーがビジーの時に、要求の特性 (ユーザー エージェントの ID、要求されているリソースのタイプ、ヘッダーの情報など) に基づいて、HTTP 要求の選択可能なブロッキングを有効にする、高度に構成可能な要求調整システムがあります。
SharePoint Foundation により、モバイル デバイスからの Web サイトへのアクセスが可能になります。これは、モバイル デバイスからの要求をモバイル機能が最適化されている特別な Web ページに自動的にリダイレクトすることにより実現されます。
SharePoint がパイプラインを変更する方法
このセクションでは、SharePoint Foundation が、インストール時に統合要求パイプラインを変更する方法と変更する個所について説明します。ただし最も重要な変更点についてのみ説明します。サブセクションに記述された変更内容に続くかっこ内の太字の番号は、「SharePoint がパイプラインを変更する理由」のリストの番号に対応しており、変更は番号の内容をサポートするためのものです。
注意
SharePoint Foundation は、パイプラインの変更の他に、インストール時にフロントエンド Web サーバーに対して他の構成変更も行います。たとえば、最初の SharePoint Foundation Web アプリケーション、SharePoint Foundation サーバーの全体管理アプリケーション、および SharePoint Services プラットフォーム用に IIS Web サイトとアプリケーション プールを作成します (これらの Web サイトとアプリケーション プールの最後は、SharePoint Foundation のインストールによって削除される UUDI Web サイトとアプリケーション プールに取って代わります)。また、Business Data Connectivity (BDC) service、セキュリティ トークン、要求ベースのセキュリティをサポートするアプリケーション プールも作成します。このような他の変更は、構成ファイルの階層にも存続しますが、ここでは説明しません。
ASP.NET フレームワーク レベルでのパイプラインの変更
なし。SharePoint Foundation は、machine.config ファイルまたはグローバルな web.config ファイルは変更しません。
IIS 構成レベルでのパイプラインの変更
SharePoint Foundation は、IIS 構成ストア (applicationhost.config) は変更しません。最も重要な変更は次のとおりです。
SharePoint Foundation は、owssvr.dll を SharePoint14Module というグローバルなモジュールとして登録します。このアンマネージ アセンブリは、データに対する要求をフロントエンド Web サーバーから SharePoint Foundation データベースに送信する主要な手段です。アンマネージ リソースを対象とする SharePoint Foundation Web アプリケーションへの要求を処理します (as?x ファイルなどの ASP.NET リソースはマネージ リソースです)。アンマネージ アセンブリを登録すると、特定の IIS Web サイト (つまり SharePoint Foundation Web アプリケーション) は独自の使用目的でそのアセンブリを利用できるようになります (マネージ モジュールはグローバルに登録する必要はありません)。owssvr.dll の詳細については、「リモート プロシージャ コール プロトコル」とその下位のトピックを参照してください。以下は登録を示しています (パス内の改行はオリジナルにはありません)。[2 と 3]
注意
このトピックの SharePoint Foundation 構成ファイルはすべて、プレリリース版の SharePoint Foundation 構成ファイルからの抜粋です。説明のためのもので、リリースされる製品のファイルの内容が示されているわけではありません。
<system.webServer> ... <globalModules> ... <!-- Other Unmanaged Modules --> ... <add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" /> </globalModules> </system.webServer>一部の IT 部門では、サーバー上で実行可能な ISAPI 拡張機能を、applicationhost.config ファイルの <isapiCgiRestriction> セクションで具体的に記述されているものに制限したいと考えます。このポリシーに対応するために、SharePoint Foundation は、owssvr.dll と 3 つの密接に関連したアセンブリをこのセクションに追加します。以下に登録を示します (パス内の改行はオリジナルにはありません)。[2]
<system.webServer> ... <security> ... <isapiCgiRestriction notListedIsapisAllowed="false" notListedCgisAllowed="false"> ... <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_aut\author.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_adm\admin.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\shtml.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> </isapiCgiRestriction> ... </security> ... </system.webServer>SharePoint Foundation が SharePoint Foundation Web アプリケーション用の IIS Web サイトとアプリケーション プールを作成すると、<site> セクションが applicationhost.config に作成されます。このセクションの主な目的は、virtualDirectory 要素を使用して、仮想ディレクトリを物理ディレクトリにマップすることです。以下は <site> セクションからの抜粋です (パス内の改行はオリジナルにはありません)。[2]
<site name="SharePoint - 80" id="2055865624" serverAutoStart="true"> <application path="/" applicationPool="SharePoint - 80"> <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\wss\VirtualDirectories\80" /> <virtualDirectory path="/_vti_bin" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi" /> <virtualDirectory path="/_layouts" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\layouts" /> <virtualDirectory path="/_controltemplates" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\controltemplates" /> ... </application> ... </site>
SharePoint Web アプリケーション レベルでのパイプラインの変更
SharePoint Foundation Web アプリケーション (および対応する IIS Web サイト) が作成されると、web.config ファイルがルートに追加されます。このファイルには、構成階層の上位レベルで作成された設定に対する追加や上書きを行う次の構成設定が含まれます。このファイルの詳細と SharePoint Foundation 開発プロジェクトでファイルを変更する方法は、「Web.config ファイルを使用して作業する」を参照してください。
<SafeMode> セクションは、セーフ モード処理システムを構成します。以下は、インストール直後の標準的な SharePoint FoundationSafeMode 要素です。CallStack 属性が false に設定されていることに注意してください。これにより、ASP.NET が、本来、報告するほとんどのシステム例外情報がブロックされます。これは、情報流出を防ぐ目的で行われます。[5 と 6]
SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false"> ... </SafeMode><SafeControls> セクションでは、セーフ モードで実行可能なコントロールを指定します。カスタマイズされたサイト ページはセーフ モードで動作しますが、アプリケーション ページは動作しません。これによって、サイト ページ上で実行するための管理者アクセス許可を持たないコントロールを含むサイト ページを、ユーザーは追加できなくなります (ユーザーにはアプリケーション ページを追加する権限がありません)。セクション内の各 SafeControl 要素は、特定のコントロール クラスを安全だとアセンブリに登録できます。ワイルドカードを使用すると複数のクラスを登録できます (独自の他の SafeControl 要素を、開発プロジェクトの展開の一部としてファイルに追加できます。詳細は、「[方法] 追加の .config ファイルを作成する」と「SafeControl 要素 (ソリューション)」を参照してください)。以下は <SafeControls> セクションからの抜粋です。[5 と 6]
<SharePoint> ... <SafeControls> <SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other ASP.NET classes --> ... <SafeControl Assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="SqlDataSource" Safe="False" AllowRemoteDesigner="False" /> ... <!-- SharePoint classes from earlier versions of the SharePoint assemblies --> ... <SafeControl Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other SharePoint classes from the current version of the SharePoint assemblies --> ... <SafeControl Src="~/_controltemplates/*" IncludeSubFolders="True" Safe="True" AllowRemoteDesigner="True" /> ... </SafeControls> ... </SharePoint>引用の最後の SafeControl 要素によって、%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES ディレクトリにマップしている仮想ディレクトリ _controltemplates に、コンパイルされていない ascx コントロールが安全だと登録されていることに注目してください。
<pages> セクションが追加されています。このセクションは、安全でないコントロールの有無を調べる (PageParserFilter から派生した) カスタムの SharePoint Foundation ページ パーサー フィルターを特定します。またこのフィルターは、ページをコンパイルする必要があるか、コンパイル以外のモードでページを提供する必要があるかどうかを判断します。以下に登録を示します。[4、5、および 6]
<pages enableSessionState="false" enableViewState="true" enableViewStateMac="true" validateRequest="false" pageParserFilterType="Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" asyncTimeout="7"> ... </pages><modules> セクションは、継承された構成を次の方法で上書きします。
runAllManagedModulesForAllRequests 属性が true に設定されます。これは、IIS 構成ストアで設定されている "managedHandler" という必須条件を上書きする効果があります。そのためパイプラインのマネージ コード部分 (ユーザーの認証など、ASP.NET によって提供されるものを含む) がすべての要求に適用されます。このとき、要求されたリソースがマネージ タイプであるかどうか、または ASP.NET への特定の関連付けがあるかどうかは関係ありません。[3]
SharePoint Foundation が使用しない一部のモジュールが削除され、SharePoint14Module (owssvr.dll ファイルの別名) などの別のモジュールが追加されます (このアンマネージ モジュールは、IIS 構成ストアにグローバル モジュールとして登録されます。この Web アプリケーションが使用するために、ここでは有効になっている必要があります)。[2]
SPRequestModule も追加されます。このマネージ モジュールは、以下のタスクを実行します。
VirtualPathProvider を実装する内部クラスのオブジェクトである SharePoint Foundation 仮想パス プロバイダーを登録します。パス プロバイダーは URL インタープリターとして機能します。たとえば、サイトの所有者がカスタマイズしたサイト ページに対する要求が受信されると、物理ファイル システム内の場所を示す URL が表示されますが、SharePoint Foundation パス プロバイダーはその URL をコンテンツ データベースの場所に変換します。パス プロバイダーを使用すると、SharePoint Foundation は、サーバー関連とサイト関連の 2 つの異なる URL をサポートできます。これにより、マスター ページ ファイルのパスなど、特定のファイル パスに現れる "~" トークンが解決されます。パス プロバイダーは、ドキュメント ライブラリー内の要求されたファイルがチェックアウトされたかどうかを確認します。最終的に、パス プロバイダーは、仮想フォルダーを含む URL を解釈し、実際の物理 URL に解決します。パス プロバイダーが aspx ページを取得すると、ページ パーサー フィルターに渡され、安全でないコードの有無が判断されます。安全でないコードが含まれていない場合は、ファイルは ASP.NET ページ パーサーに渡されます。[2]
要求を owssvr.dll にルーティングする必要があるかどうかを判断します。ルーティングが必要な場合は、owssvr.dll が必要とする、要求内の HTTP ヘッダーの処理が行われます。[2 と 3]
パフォーマンスの監視と要求調整システムを管理します。サーバーがビジーで受信する要求をすべて処理できない場合は、要求を選択的にブロックできます。[11]
リクエストがモバイル デバイスからのものかどうかを判断します。モバイル デバイスからのリクエストの場合は、リクエストは適切なモバイル ページに転送されます。[12]
以下に <modules> セクションを示します。
<system.webServer> ... <modules runAllManagedModulesForAllRequests="true"> <remove name="AnonymousIdentification" /> <remove name="FileAuthorization" /> <remove name="Profile" /> <remove name="WebDAVModule" /> <add name="SPRequestModule" preCondition="integratedMode" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="SharePoint14Module" preCondition="integratedMode" /> </modules> ... </system.webServer>
<handlers> セクションでは、主に、SharePoint Foundation が使用しない一部の HTTP ハンドラーを削除したり、AJAX をサポートするハンドラーを追加したりすることにより、継承された構成を上書きします。また owssvr.dll は、OwssvrHandler の下に HTTP ハンドラーとして登録されます。MapRequestHandler イベント中に要求をルーティングできるようにするには、この登録が必要です (アンマネージ リソースに対する要求は、OwssvrHandler によって処理されます)。要求ライフサイクルにおけるイベントの詳細については、「ASP.NET Application Life Cycle Overview for IIS 7.0」を参照してください。以下に <handlers> セクションを示します (パス内の改行はオリジナルにはありません)。[3 と 10]
<system.webServer> ... <handlers> <remove name="OPTIONSVerbHandler" /> <remove name="WebServiceHandlerFactory-Integrated" /> <remove name="svc-Integrated" /> <remove name="WebDAV" /> <add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode" /> <add name="OwssvrHandler" scriptProcessor="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi\owssvr.dll" path="/_vti_bin/owssvr.dll" verb="*" modules="IsapiModule" preCondition="integratedMode" /> <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </handlers> </system.webServer>SharePoint Foundation のクライアント オブジェクト モデルとクライアント側のプログラミングをサポートするために、<microsoft.sharepoint.client> セクションが追加されています (このオブジェクト モデルの詳細については、「クライアント API の使用」を参照してください)。以下のマークアップで、このセクションを示します。[7]
<microsoft.sharepoint.client> <serverRuntime> <hostTypes> <add type="Microsoft.SharePoint.Client.SPClientServiceHost, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </hostTypes> </serverRuntime> </microsoft.sharepoint.client>Web パーツとコントロール数の制限をサポートするために、セクションがいくつか追加されています。[5 と 6]
<WebPartLimits MaxZoneParts="50" PropertySize="1048576" /> <WebPartCache Storage="CacheObject" /> <WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />SharePoint Foundation のワークフローをサポートするために、<WorkflowServices> セクションと <System.Workflow.ComponentModel.WorkflowCompiler> セクションが追加されています。以下のマークアップは <WorkflowServices> セクションを示し、その下は <System.Workflow.ComponentModel.WorkflowCompiler> セクションの引用です。[8]
<SharePoint> ... <WorkflowServices> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOEWSSService"> </WorkflowService> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOETaskService"> </WorkflowService> </WorkflowServices> </SharePoint> ... <System.Workflow.ComponentModel.WorkflowCompiler> <authorizedTypes> <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Runtime" TypeName="CorrelationToken" Authorized="True" /> <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Guid" Authorized="True" /> ... <-- Other mscorlib classes --> ... <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowActivationProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowTaskProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowHistoryEventType" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPItemKey" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowUserContext" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions" TypeName="*" Authorized="True" /> </authorizedTypes> </System.Workflow.ComponentModel.WorkflowCompiler>2 つの信頼レベル (WSS_Minimal と WSS_Medium) を追加するために、<securityPolicy> セクションが使用されています。この信頼レベルは、%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG ディレクトリにあるファイルで定義されます。以下のマークアップは <securityPolicy> セクションを示します (パス内の改行はオリジナルにはありません)。[5]
<system.web> <securityPolicy> <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_mediumtrust.config" /> <trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_minimaltrust.config" /> </securityPolicy> ... </system.web><compiliation> セクションは、SharePoint Foundation as?x ファイルのコンパイルに使用できる 4 つの追加アセンブリをページ パーサーに示します。また、ASP.NET ページと SharePoint Foundation Web アプリケーション内の他の as?x コントロールを処理するためにページ パーサーが使用する 4 つの専門の式ビルダーを指定します。以下のマークアップは <compiliation> セクションを示します。[9]
<system.web> ... <compilation batch="false" debug="false"> <assemblies> <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </assemblies> <expressionBuilders> <remove expressionPrefix="Resources" /> <add expressionPrefix="Resources" type="Microsoft.SharePoint.SPResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPHtmlEncodedResources" type="Microsoft.SharePoint.SPHtmlEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPSimpleFormattingEncodedResources" type="Microsoft.SharePoint.SPSimpleFormattingEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SatelliteResources" type="Microsoft.SharePoint.Search.SPSatelliteResourceExpressionBuilder, Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </expressionBuilders> </compilation> ... </system.web><sitemap> セクションでは、4 つの特別な SharePoint Foundation サイト マップ プロバイダーを指定します。以下のマークアップは、<sitemap> セクションを示します。[1]
<system.Web> ... <siteMap defaultProvider="SPSiteMapProvider" enabled="true"> <providers> <add name="SPNavigationProvider" type="Microsoft.SharePoint.Navigation.SPNavigationProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPSiteMapProvider" type="Microsoft.SharePoint.Navigation.SPSiteMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPContentMapProvider" type="Microsoft.SharePoint.Navigation.SPContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPXmlContentMapProvider" siteMapFile="_app_bin/layouts.sitemap" type="Microsoft.SharePoint.Navigation.SPXmlContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </providers> </siteMap> ... </system.Web>
注意
SharePoint Foundation サーバーの全体管理アプリケーションが SharePoint Foundation Web アプリケーション、ひいては IIS Web サイトとして実装されます。このアプリケーションには、上述した web.config に非常によく似たルート web.config ファイルがあります。主な違いは、サーバーの全体管理アプリケーションがセッション状態をサポートし、追加のサイト マップ プロバイダーと一部の追加コントロールを安全だと登録する点です。SharePoint Services プラットフォームをホストする IIS Web サイトには、非常に小さいルート web.config もあります。これは、要求ベースのセキュリティをサポートするプロバイダーの登録に使用されます。
ディレクトリ レベルでのパイプラインの変更
SharePoint Foundation は、特定の物理ディレクトリまたは仮想ディレクトリ内のリソースに対する要求のみに適用される web.config ファイルによって、要求パイプラインをさらに改善します。1 つの例を挙げると、SharePoint Foundation は、モバイル デバイス上に表示するために設計されたアプリケーション ページとフォームを提供します。これらは仮想ディレクトリ _layouts\mobile (物理ディレクトリ %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\ にマップしている) に格納されています。このディレクトリには、ページ上に表示されるデータ量の制限を設定する web.config ファイルがあります。また、ページを要求したモバイル デバイスの能力に応じてページのレンダリング方法を管理する一連のフィルターも登録します。
関連項目
その他の技術情報
ASP.NET Application Life Cycle Overview for IIS 7.0
ASP.NET Configuration Overview