Microsoft SharePoint Foundation como aplicación de ASP.NET
Última modificación: viernes, 28 de enero de 2011
Hace referencia a: SharePoint Foundation 2010
En este artículo
Configuración de IIS y ASP.NET
La canalización de solicitudes
Por qué SharePoint modifica la canalización
Cómo modifica SharePoint la canalización
En este tema se explica cómo se construye Microsoft SharePoint Foundation en un conjunto de modificaciones de la canalización de solicitudes integrada de Internet Information Services (IIS) y Microsoft ASP.NET.
Nota
En este tema se describe cómo IIS y ASP.NET funcionan en modo integrado. También pueden funcionar en modo clásico, pero debido a que las aplicaciones web de SharePoint Foundation deben estar en grupos de aplicaciones para usar el modo integrado, no se brinda más información sobre el modo clásico en este tema.
Nota
Aunque este tema trata sobre archivos web.config y archivos relacionados, no explica cómo personalizar estos archivos. Para obtener más información acerca de personalizar la configuración de SharePoint Foundation, vea Trabajo con archivos Web.config.
Configuración de IIS y ASP.NET
Las opciones de configuración para IIS, ASP.NET, y los sitios web, aplicaciones y servicios construidos en ellos, se almacenan en una jerarquía de archivos de configuración. El principio general es que cada archivo de la jerarquía tiene un ámbito más acotado que el de los archivos que están arriba y puede invalidar, dentro de su ámbito, la configuración de dichos archivos. También se pueden bloquear algunas opciones de configuración de uno de los archivos de arriba. De esta manera se evita que los archivos que están más abajo en la jerarquía invaliden las opciones de configuración bloqueadas.
En la parte superior de la jerarquía se encuentra el archivo machine.config, que está en el directorio %WinDir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\. El mismo contiene la configuración de todo el servidor.
Un segundo archivo que contiene la configuración de todo el servidor es el archivo global web.config, que está ubicado en el mismo directorio.
Nota
SharePoint Foundation 2010 usa Microsoft ASP.NET 3.5, aún cuando hay instalada una versión más reciente de ASP.NET en el servidor front-end web. Sin embargo, la versión 3.5 no cambió el archivo predeterminado machine.config, ni el archivo global web.config. La versión más reciente anterior a la de la aplicación que cambió estos archivos es Microsoft ASP.NET 2.0; por este motivo, los archivos están ubicados en la rama de versión 2.0 de la carpeta %WinDir%\Microsoft.NET\Framework64\.
Un tercer archivo de configuración de todo el servidor es el almacén de configuración de IIS, que se encuentra en el archivo applicationhost.config. El mismo está ubicado en el directorio %WinDir%\System32\inetsrv\config\ y contiene registros de los sitios web y grupos de aplicaciones de IIS del servidor, así como algunas opciones de configuración que se aplican a todas las aplicaciones del servidor web. La configuración de applicationhost.config está orientada principalmente a las partes de la canalización contribuidas por IIS, mientras que el archivo machine.config y el archivo global web.config contienen opciones de configuración orientadas principalmente a las partes de la canalización de solicitudes integrada contribuidas por ASP.NET.
Cada sitio web de IIS puede tener su propio archivo web.config en la raíz para que contenga invalidaciones específicas de sitio de la configuración que se hereda de los archivos de configuración que están más arriba en la jerarquía y para agregar opciones de configuración nuevas.
Ciertos servidores físicos o virtuales de un sitio web de IIS también pueden tener su propio archivo web.config para agregar nuevas opciones de configuración o invalidar las heredadas. Obviamente, las nuevas opciones de configuración e invalidaciones se aplican solamente a las solicitudes HTTP para recursos ubicados dentro del directorio y subdirectorios.
Nota
Una ‘aplicación web’ en la terminología de SharePoint Foundation está relacionada con lo que se denomina ‘sitio web’ en la terminología de IIS. Cada aplicación web de SharePoint Foundation se hospeda en un sitio web de IIS con el mismo nombre y, por lo general, en un solo sitio web de IIS. (Sin embargo, es posible extender una aplicación web de SharePoint Foundation a un puerto adicional, en cuyo caso se hospeda en un sitio web de IIS más). Por este motivo, es posible que vea referencias en la documentación de SharePoint Foundation al archivo raíz web.config de una aplicación web o a un archivo web.config en el directorio de una aplicación web. A lo que realmente se hace referencia es a las raíces y directorios del sitio web de IIS correspondiente.
El esquema XML que usan estos archivos de configuración se describe en IIS 7.0: Settings Schema. Vea también ASP.NET Configuration Overview y el tema sobre el el sistema de configuración en IIS 7.0.
La canalización de solicitudes
Cuando un servidor front-end web recibe una solicitud de un cliente, la misma pasa a través de una canalización de unidades que la procesan. Este procesamiento incluye la autenticación del usuario, la verificación de la autorización del usuario, la construcción de la respuesta y, por último, el registro de la solicitud. Históricamente, algunas de las unidades se originaron en versiones anteriores de IIS y otras en ASP.NET, pero la diferencia de orígenes no es importante en SharePoint Foundation.
Controladores HTTP
La respuesta a cualquier solicitud la produce un objeto de controlador HTTP. Los archivos *.config asignan las solicitudes a uno u otro objeto de controlador HTTP (o a otra clase de generadores de controladores que crean objetos de controlador HTTP) según el recurso solicitado y el verbo HTTP de la solicitud. Por ejemplo, en una instalación sin modificar de ASP.NET, una solicitud de un archivo aspx; es decir, una página de ASP.NET, con el verbo "GET" se envía a un objeto PageHandlerFactory que crea un objeto Page para procesar la solicitud. Solo las clases que, como la clase Page, implementan la clase IHttpHandler pueden ser controladores HTTP de código administrado. La asignación de un par recurso/verbo a un controlador (o a un generador de controladores) se especifica en el elemento secundario handlers del elemento system.webServer. A continuación se muestra un ejemplo del elemento handlers, con la mayoría de los elementos secundarios omitidos para hacerlo más breve.
<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>
El atributo overrideMode del elemento location se establece como "Permitir" para que los archivos *.config que están mas abajo en la jerarquía puedan tener sus propios elementos handler para invalidar la configuración allí. El atributo path se establece en la cadena vacía para que esta configuración se aplique luego a todos los sitios web de IIS a menos que se invaliden en un archivo *.config.
Módulos HTTP
La canalización de solicitudes contiene también módulos HTTP. Los módulos son ensamblados que, generalmente, contienen uno o más controladores de eventos o que definen eventos nuevos que otros módulos pueden controlar. Un módulo HTTP se puede registrar para uno o más eventos en el ciclo de vida de la solicitud. Por lo general, se usan para preprocesar y procesar posteriormente solicitudes. Los módulos se registran en un elemento secundario modules del elemento system.webServer. A continuación se muestra el elemento modules predeterminado, con la mayoría de los elementos secundarios omitidos para hacerlo más breve.
<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>
El atributo preCondition especifica una condición que la solicitud debe cumplir antes de que se le aplique el módulo. Cuando el atributo tiene el valor "managedHandler", el módulo se aplica a solicitudes para recursos administrados (que son, principalmente, tipos de recursos de ASP.NET, como archivos aspx). La sección Cómo modifica SharePoint la canalización a continuación describe cómo SharePoint Foundation invalida este comportamiento para que los módulos se apliquen a todas las solicitudes, incluso los tipos de recursos que no son de ASP.NET, como archivos HTML estáticos. Para obtener más información sobre los módulos HTTP, vea la introducción a la arquitectura de IIS 7.0.
Por qué SharePoint modifica la canalización
A continuación, vea una lista de los motivos por los que los objetivos de SharePoint Foundation requieren que cambie la configuración predeterminada de la canalización:
SharePoint Foundation crea un mundo web nuevo y abstracto, en el que las listas y los elementos de lista, en lugar de las páginas, son las entidades principales del rellenado. Para ver e interactuar con este mundo, al menos a través de un explorador, se requiere que los datos se implementen en la parte superior del mundo web conocido de las páginas presentadas en un explorador. Pero las listas existen independientemente de cualquier página específica y una lista en particular puede aparecer en más de una página. Por este motivo, la estructura de páginas de un sitio web tiene poca importancia en SharePoint Foundation para diferentes fines.
Tenga en cuenta una implicación de tener sitios web estructurados con listas en vez de páginas. Un mapa del sitio que muestra la estructura de páginas es mucho menos interesante que el mapa de listas. Por este motivo, un mapa del sitio de contenido de listas es mucho más útil que uno de páginas.
Generalmente, si no siempre, los controladores de solicitudes de ASP.NET, suponen que la dirección URL de un recurso solicitado se asigna directamente dentro del sistema de archivos del servidor front-end web. Sin embargo, SharePoint Foundation almacena varios recursos, como páginas personalizadas, en una base de datos. Además, aún cuando un archivo está ubicado en el sistema de archivos del servidor front-end web, SharePoint Foundation usa muchos directorios virtuales, más allá de la asignación predeterminada de IIS de la raíz virtual del servidor "\" al directorio físico "inetpub\wwwroot\". Entre otros motivos, esta técnica se necesita para hacer que las páginas de aplicación de SharePoint Foundation sean parte de todas las páginas web dentro de una aplicación web de SharePoint Foundation.
De forma predeterminada, los módulos de la canalización que contribuye ASP.NET, como el módulo FormsAuthentication, solo procesan tipos de recursos relacionados con ASP.NET, como archivos aspx. Pero no hay límite para los tipos de archivo que se pueden almacenar en una biblioteca de documentos de SharePoint Foundation; SharePoint Foundation necesita que estos módulos procesen todas las solicitudes, independientemente del tipo de recurso. Por ejemplo, si un usuario recibe un correo electrónico con un vínculo a un archivo docx de una biblioteca de documentos de SharePoint Foundation, dicho usuario se deberá autenticar antes de obtener acceso al archivo.
De forma predeterminada, ASP.NET compila todas las páginas aspx en un ensamblado que se carga en la memoria la primera vez que se solicita. Generalmente, las implementaciones de SharePoint Foundation tienen demasiadas páginas aspx como para que esto sea viable; la memoria de los servidores front-end web se retraería y no hay manera de descargar estos ensamblados de la memoria en forma dinámica. Por lo tanto, SharePoint Foundation debe servir a la mayoría de las páginas aspx en modo de descompilación.
SharePoint Foundation habilita la delegación de administración. Aunque los trabajadores de TI siguen administrando los servidores y los conjuntos o granjas de servidores, muchas de las tareas que tradicionalmente han formado parte del trabajo de los profesionales de TI o diseñadores web (como la creación de páginas de sitio y sitios web nuevos) recaen en SharePoint Foundation en usuarios que los profesionales de TI considerarían como principiantes. La delegación de autoridad en personas no profesionales requiere un patrón de confianza y un control de permisos más complejos.
El diseño de ASP.NET, por lo general, asume que solo las personas que tienen derechos de administrador agregan páginas aspx nuevas a un sitio web. Por lo tanto, la aplicación confía en cualquier control en cualquiera de estas páginas. Sin embargo, SharePoint Foundation permite que un rango de usuarios finales mucho más amplio agregue páginas aspx; cualquiera que tenga el permiso para agregar y personalizar páginas puede hacerlo. Esto requiere que SharePoint Foundation tenga un sistema que permita que los administradores limiten los controles que se permiten en las páginas. Además, debido a que estas páginas creadas por usuarios pueden tener elementos web, los administradores necesitan una manera de limitar la cantidad de elementos web y controles. También es necesario limitar los controles y los elementos web agregados por el usuario en cuanto al tipo de código que pueden ejecutar para evitar que el código errante bloquee el servidor web. SharePoint hace que esto se cumpla al requerir que estos controles se ejecuten en un modo de ejecución restringido, denominado modo seguro.
SharePoint Foundation expone un modelo de objetos de cliente en un ensamblado que se instala en equipos cliente. Este ensamblado permite que se envíe código al servidor y se ejecute en modo por lotes. Esto requiere que un host del servidor se ocupe de los lotes. No existe nada como esto integrado a ASP.NET. No tiene ensamblados del lado del cliente.
SharePoint Foundation admite flujos de trabajo y está integrado a Windows Workflow Foundation.
SharePoint Foundation tiene un gran sistema de recursos globalizados a los que se hace referencia en sus archivos .aspx y .ascx. Esto requiere generadores de expresión especializados.
La compatibilidad de ASP.NET con AJAX se volvió a diseñar parcialmente para Microsoft ASP.NET 3.5, y SharePoint Foundation admite el nuevo diseño con controladores personalizados.
SharePoint Foundation tiene un sistema de limitación de solicitudes muy configurable que permite el bloqueo selectivo de solicitudes HTTP cuando un servidor está ocupado, basado en las características de la solicitud, como la identidad del agente de usuario, el tipo de recurso que se solicita y la información del encabezado.
SharePoint Foundation habilita el acceso a sus sitios web desde dispositivos móviles. Esto se logra al redirigir automáticamente las solicitudes de los dispositivos móviles a versiones de las páginas web especiales optimizadas para móviles.
Cómo modifica SharePoint la canalización
En esta sección se describe cómo y dónde SharePoint Foundation realiza cambios en la canalización de solicitudes integrada cuando está instalado. Sin embargo, solo se tratan los cambios más importantes. Los números en negrita, que aparecen entre corchetes después de los cambios descritos en las subsecciones siguientes, indican qué requisitos de la lista dePor qué SharePoint modifica la canalización admite cada cambio.
Nota
Además de modificar la canalización, SharePoint Foundation realiza otros cambios en la configuración de los servidores front-end web cuando está instalado. Por ejemplo, crea sitios web de IIS y grupos de aplicaciones para una primera aplicación web de SharePoint Foundation, para la aplicación de administración central de SharePoint Foundation y para la plataforma de SharePoint Services. (Este último sitio web y grupo de aplicaciones reemplaza al sitio web y grupo de aplicaciones de UDDI, que se elimina al instalar SharePoint Foundation.) También crea grupos de aplicaciones para admitir el Servicio de conectividad de datos profesionales (BDC), tokens de seguridad y seguridad basada en notificaciones. Estos otros cambios también persisten en la jerarquía de archivos de configuración, pero no se tratan aquí.
Cambios en la canalización a nivel de ASP.NET Framework
Ninguno. SharePoint Foundation no realiza cambios en el archivo machine.config ni en el archivo global web.config.
Cambios en la canalización a nivel de configuración de IIS
SharePoint Foundation cambia el almacén de configuración de IIS (applicationhost.config). Los cambios más importantes son los siguientes:
SharePoint Foundation registra owssvr.dll como un módulo global llamado SharePoint14Module. Este ensamblado no administrado es un medio principal por el que se transmiten solicitudes de datos desde los servidores front-end web a las bases de datos de SharePoint Foundation. El mismo controla las solicitudes de recursos no administrados a la aplicación web de SharePoint Foundation. (Los recursos de ASP.NET, como archivos as?x, son recursos administrados.) El registro de un ensamblado no administrado hace que esté disponible para ciertos sitios web (y, por lo tanto, para aplicaciones web de SharePoint Foundation) para que lo habiliten para uso propio. (Los módulos administrados no se tienen que registrar globalmente.) Para obtener más información acerca de owssvr.dll, vea Protocolo de llamada a procedimiento remoto y sus temas secundarios. A continuación se muestra el registro. (Los saltos de línea de la ruta de acceso no aparecen en el original.) [2 y 3]
Nota
Todos los extractos de archivos de configuración de SharePoint Foundation que se proporcionan en este tema se obtuvieron de una versión preliminar de SharePoint Foundation. Se brindan a modo de ilustración y no necesariamente muestran contenidos de los archivos del producto comercializado.
<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>Algunos departamentos de TI quieren restringir las extensiones ISAPI que se pueden ejecutar en los servidores a aquellas que se detallan específicamente en una sección lt;isapiCgiRestriction> del archivo applicationhost.config. Para cumplir esta directiva, SharePoint Foundation agrega owssvr.dll y otros tres ensamblados relacionados a esta sección. A continuación se muestra el registro. (Los saltos de línea de la ruta de acceso no aparecen en el original.) [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>Cuando SharePoint Foundation crea sitios web y grupos de aplicaciones de IIS para una aplicación web de SharePoint Foundation, se crea una sección <site> en applicationhost.config. El objetivo principal de esta sección es la asignación de directorios virtuales a directorios físicos con elementos del virtualDirectory. A continuación se muestra un extracto de una sección <site>. (Los saltos de línea de las rutas de acceso no aparecen en el original.) [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>
Cambios en la canalización a nivel de aplicaciones web de SharePoint
Cuando se crea una aplicación web de SharePoint Foundation (y su correspondiente sitio web de IIS) se agrega un archivo web.config a la raíz. Este archivo contiene la siguiente configuración, que se agrega a, o invalida, la configuración en niveles superiores de la jerarquía de configuración. Para obtener más información sobre este archivo y cómo se puede modificar en proyectos de desarrollo de SharePoint Foundation, vea Trabajo con archivos Web.config.
Una sección <SafeMode> configura el sistema de procesamiento del modo seguro. A continuación se proporciona el elemento SafeMode estándar de SharePoint Foundation inmediatamente después de la instalación. Tenga en cuenta que el atributo CallStack está establecido en false. De esta manera, se bloquea la mayor parte de la información de excepciones del sistema que ASP.NET notificaría. El objetivo es evitar que se divulgue la información. [5 y 6]
SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false"> ... </SafeMode>Una sección <SafeControls> especifica los controles que se pueden ejecutar en modo seguro. Las páginas de sitio personalizadas se ejecutan en modo seguro, pero no ocurre lo mismo con las páginas de aplicación. De esta manera se asegura que los usuarios no puedan agregar una página de sitio que contenga un control que no tiene permiso de un administrador para ejecutarse en una página de sitio. (Los usuarios no tienen derechos para agregar páginas de aplicación). Todos los elementos SafeControl de la sección pueden registrar una clase de control en particular en un ensamblado como segura, o varias clases usando caracteres comodín. (Puede agregar sus propios elementos SafeControl adicionales al archivo como parte de la implementación del proyecto de desarrollo. Para obtener más información sobre cómo realizar esta tarea, vea Procedimiento para crear un archivo adicional .config y Elemento SafeControl (Solución)). A continuación se muestra un extracto de la sección <SafeControls>. [5 y 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>Tenga en cuenta que el último elemento SafeControl del extracto registra como seguros los controles ascx sin compilar en el directorio virtual _controltemplates, que asigna el directorio %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES.
Se agrega una sección <pages>, que identifica el filtro del analizador personalizado de la página de SharePoint Foundation (que deriva de PageParserFilter), que busca controles no seguros. El filtro también determina si la página se debe compilar o servir en modo de no compilación. A continuación se muestra el registro. [4, 5 y 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>Una sección <modules> invalida la configuración heredada de las siguientes maneras:
El atributo runAllManagedModulesForAllRequests está establecido en true. Esto invalida la condición previa "managedHandler" establecida en el almacén de configuración de IIS; por lo tanto, las partes de código administrado de la canalización (incluidas las que contribuye ASP.NET, como la autenticación del usuario) se aplican a todas las solicitudes, independientemente de si el recurso que se solicitó es de un tipo administrado o si tiene alguna asociación en particular con ASP.NET. [3]
Se quitan algunos módulos que SharePoint Foundation no usa y se agregan otros, incluido SharePoint14Module, que es otro nombre para el archivo owssvr.dll. (Este módulo no administrado se registra en el almacén de configuración de IIS como un módulo global. También se debe habilitar aquí para que esta aplicación web lo pueda usar.) [2]
Se agrega también SPRequestModule. Este módulo administrado realiza las siguientes tareas:
Registra el proveedor de ruta de acceso virtual de SharePoint Foundation, un objeto de una clase interna que implementa VirtualPathProvider. El proveedor de ruta de acceso virtual funciona como un intérprete de direcciones URL. Por ejemplo, si se recibe una solicitud para una página de un sitio cuyo propietario ha personalizado, parece que la dirección URL apuntara a una ubicación en el sistema de archivos físico. Sin embargo, el proveedor de rutas de acceso de SharePoint Foundation traduce la dirección URL a una ubicación en la base de contenidos. El proveedor de ruta de acceso también habilita la compatibilidad de SharePoint Foundation con dos tipos de direcciones URL distintas: relativa al servidor y relativa al sitio. Resuelve los tokens "~" que aparecen en ciertas rutas de acceso a archivos, como las rutas de acceso a archivos de páginas maestras, Comprueba si un archivo que se solicitó en una biblioteca de documentos está desprotegido. Por último, interpreta las direcciones URL que contienen carpetas virtuales y las envía a la dirección URL física real. Cuando el proveedor de ruta de acceso recupera una página aspx, la pasa al filtro del analizador de la página, el cual determina si contiene código no seguro. Si no contiene, el archivo se pasa al filtro del analizador de la página de ASP.NET. [2]
Determina si se debe redirigir una solicitud a owssvr.dll y, de ser así, procesa un poco los encabezados HTTP de la solicitud de la manera que necesita owssvr.dll. [2 y 3]
Regula la supervisión del rendimiento y el sistema de limitación de solicitudes. Puede bloquear solicitudes de manera selectiva cuando un servidor está muy ocupado para encargarse de todas las solicitudes que recibe.[11]
Determina si la solicitud proviene de un dispositivo móvil. En caso afirmativo, la solicitud se reenvía a la página móvil correspondiente. [12]
A continuación se muestra la sección <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>
Una sección <handlers> invalida la configuración heredada, principalmente, al quitar algunos controladores HTTP que SharePoint Foundation no usa y agregar otros controladores que admiten AJAX. Además, owssvr.dll se registra como controlador HTTP con el nombre OwssvrHandler. Estas acciones son necesarias para que las solicitudes se puedan redirigir a él durante el evento MapRequestHandler. (OwssvrHandler se ocupa de las solicitudes de recursos no administrados.) Para obtener más información sobre los eventos del ciclo de vida de las solicitudes, vea ASP.NET Application Life Cycle Overview for IIS 7.0. A continuación se muestra la sección <handlers>. (Los saltos de línea de las rutas de acceso no aparecen en el original.) [3 y 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>Se agrega una sección <microsoft.sharepoint.client> para admitir el modelo de objetos de cliente de SharePoint Foundation y la programación del lado del cliente. (Para obtener más información sobre este modelo de objetos, vea Uso de las API cliente.) El siguiente fragmento muestra dicha sección. [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>Se agregan varias secciones para admitir límites en los elementos web y el número de controles. [5 y 6]
<WebPartLimits MaxZoneParts="50" PropertySize="1048576" /> <WebPartCache Storage="CacheObject" /> <WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />Se agregan una sección <WorkflowServices> y una sección <System.Workflow.ComponentModel.WorkflowCompiler> para admitir flujos de trabajo en SharePoint Foundation. El siguiente fragmento muestra la sección <WorkflowServices> y debajo, un extracto de la sección <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>Se usa una sección <securityPolicy> para agregar dos niveles de confianza adicionales, WSS_Minimal y WSS_Medium. Estos se definen en archivos ubicados en el directorio %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG. El siguiente fragmento muestra la sección <securityPolicy>. (Los saltos de línea de las rutas de acceso no aparecen en el original). [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>Una sección <compiliation> notifica al analizador de la página sobre cuatro ensamblados adicionales que puede usar para compilar archivos as?x de SharePoint Foundation. También especifica cuatro generadores de expresión especiales que el analizador de la página usa para procesar páginas de ASP.NET y otros controles as?x en una aplicación web de SharePoint Foundation. El siguiente fragmento muestra la sección <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>Una sección <sitemap> especifica cuatro proveedores de mapas del sitio especiales de SharePoint Foundation. El siguiente fragmento muestra la sección <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>
Nota
La aplicación de administración central de SharePoint Foundation se implementa como una aplicación web de SharePoint Foundation; y, por lo tanto, como un sitio web de IIS. Tiene también un archivo raíz web.config que es muy similar al archivo web.config descrito anteriormente. La diferencia principal es que la aplicación de administración central admite estados de sesión y registra proveedores de mapas del sitio adicionales y algunos otros controles como seguros. El sitio web de IIS que hospeda la plataforma de SharePoint Services también tiene un archivo raíz web.config muy pequeño. El mismo se usa para registrar proveedores que admiten seguridad basada en notificaciones.
Cambios en la canalización a nivel del directorio
SharePoint Foundation refina aún más la canalización de la solicitud con archivos web.config que se aplican solamente a solicitudes de recursos dentro de directorios físicos o virtuales específicos. Aquí se brinda un ejemplo: SharePoint Foundation proporciona versiones de sus páginas y formas de aplicación diseñadas para que se vean en dispositivos móviles. Estas están ubicadas en el directorio virtual _layouts\mobile (que está asignado al directorio físico %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Este directorio contiene un archivo web.config que establece límites a la cantidad de datos que se muestran en la página. Además, registra una serie de filtros que controlan cómo se presenta la página, según las capacidades del dispositivo móvil que solicitó la página.
Vea también
Otros recursos
ASP.NET Application Life Cycle Overview for IIS 7.0
ASP.NET Configuration Overview