Comment protéger les fichiers statiques avec ASP.NET authentification de formulaire sur IIS 7.5?

J'ai eu le même problème avec l'authentification des rôles. Par essais et erreurs, j'ai finalement réussi à le faire fonctionner avec une petite modification du code de @ Joel Cunningham:

<modules runAllManagedModulesForAllRequests="true" >

J'ai utilisé ces deux sites de références: http://forums.iis.net/t/1177964.aspx et http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/

C'est un vieux fil, mais je suis arrivé dessus et j'ai rencontré le même problème que Egil. Voici la version du correctif de Joel qui inclut les rôles:

<modules runAllManagedModulesForAllRequests="false">
      <remove name="FormsAuthenticationModule" />
      <add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
      <remove name="UrlAuthorization" />
      <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
      <remove name="RoleManager" />
      <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
      <remove name="DefaultAuthentication" />
      <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>

Je voulais savoir pourquoi il serait nécessaire de Ré-ajouter des modules (avec des options par défaut) qui sont ajoutés par défaut pour le Pipeline intégré, donc j'ai creusé un peu plus profond.

Vous devez supprimer et ré-ajouter les modules car, par défaut, les modules ne sont pas ajoutés avec les options par défaut. Ils ont une condition préalable ajoutée pour que la rétrocompatibilité ne s'exécute que pour le contenu géré par un inscrit ASP.NET gestionnaire (par exemple, .pages aspx).

La valeur par défaut ressemble à ce:

<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
         preCondition="managedHandler" />

En supprimant les modules et en les rajoutant sans condition préalable, ces modules individuels s'exécutent pour chaque requête (y compris votre contenu statique). Il est plus granulaire que d'activer runAllManagedModulesForAllRequests.

Vous pouvez lire à ce sujet dans quelques articles à partir du moment où le Pipeline intégré a été introduit avec IIS 7:

• ASP.NET intégration avec IIS 7
• Comment tirer parti du Pipeline intégré IIS 7.0

Notez que il y a une faute de frappe ou le nom du module dans le deuxième article (et la réponse de @John) a été changé de FormsAuthenticationModule à FormsAuthentication à un moment donné.

L'ensemble des modules de travail dans IIS 7.5 à 8.5 ressemble à ceci pour moi:

<system.webServer>
  <modules>
    <!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
    <remove name="FormsAuthentication" />
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
    <remove name="DefaultAuthentication" />
    <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
    <remove name="RoleManager" />
    <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
    <remove name="UrlAuthorization" />
    <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
  </modules>
</system.webServer>

Additif:

Comme @ eych l'a noté, cela bloque également l'accès au dossier ~/Content (ou partout où vous avez votre CSS), et ~/Scripts, et ainsi de suite.

Si vous voulez autoriser des exceptions - c'est-à-dire permettre à certains fichiers/dossiers d'être accessibles par des utilisateurs non authentifiés-vous pouvez le faire au moyen de l'élément location. Ajouter ce qui suit à web.config:

  <location path="Content">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Mise à Jour: Une meilleure solution est de laisser l'accès par défaut -- qui permettra l'accès à votre CSS / JavaScript / etc. -- et appliquez le "lock" (uniquement) au dossier où le contenu statique est stocké:

<location path="data">
  <system.web>
    <authorization>
      <deny users="?"/>
    </authorization>
  </system.web>
</location>

Mise en garde: dans notre cas (un site MVC), nous avions besoin de décorer toutes nos actions de contrôleur (sauf login) avec [AuthorizeAttribute]. Ce qui est une bonne idée de toute façon, mais n'avait pas été nécessaire auparavant (car auparavant toute requête non autorisée était redirigée vers la page de connexion).

Si votre pool d'applications s'exécute en mode classique, vous pouvez effectuer les opérations suivantes. Vous devrez répéter ces étapes pour chaque extension de fichier que vous souhaitez gérer, mais j'utilise .html ici.

Tout d'abord, ajoutez un fournisseur de génération de page sur le Web.configuration:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <compilation>
      <buildProviders>
        <add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
      </buildProviders>
    </compilation>
  </system.web> 
</configuration>

Puis ajoutez une usine de gestionnaire de page:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <httpHandlers>
      <add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
    </httpHandlers>
  </system.web> 
</configuration>

Puis ajoutez un gestionnaire de page:

<?xml version="1.0" encoding="UTF-8"?>
<configuration> 
  <system.webServer>
    <handlers>
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
    </handlers>
  </system.webServer>
</configuration>

Cela a fonctionné pour moi. (Crédit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)