Ok donc ce n'est pas grave, mais ça me dérange et je ne peux pas le laisser partir.
J'utilise donc MVC 5.1 avec .NET 4.5.1 et l'authentification OWIN. Ainsi, lorsque vous créez un nouveau projet MVC 5, les éléments suivants sont automatiquement ajoutés au Web.config pour se débarrasser du module http d'authentification par formulaire, car il n'est plus nécessaire lors de l'utilisation du middleware OWIN:
<system.webServer>
<modules>
<remove name="FormsAuthenticationModule" />
</modules>
</system.webServer>
Maintenant que nous supprimons le module, cela signifie qu'il a été ajouté précédemment, voici donc l'entrée enregistrant ce module http dans C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
:
<httpModules>
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
</httpModules>
Et voici l'entrée dans C:\Windows\System32\inetsrv\config\applicationHost.config
pour IIS 8.5 qui indique à mon application d'utiliser le module:
<system.webServer>
<modules>
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" />
</modules>
</system.webServer>
Ainsi, ce qui est automatiquement ajouté à ma configuration Web au niveau de l'application a un attribut de nom "FormsAuthenticationModule" tandis que les entrées dans les deux fichiers de configuration de niveau serveur/asp.net utilisent l'attribut de nom "FormsAuthentication". Que se passe-t-il? Il me semble que le module ne sera pas supprimé car l'attribut name ne correspond pas. Je penserais simplement que c'était une faute de frappe, mais après une recherche en ligne, tout le monde semble utiliser "FormsAuthenticationModule" dans l'application web.config. S'agit-il d'un changement récent dans la nouvelle version d'asp.net/iis ou est-ce que je manque quelque chose?
Vous avez raison - c'est une faute de frappe dans le modèle.
Un effet secondaire majeur de cette "faute de frappe" est qu'il laissera FormsAuthentication sur le fait que le chemin de connexion d'owin sera ignoré et que les appels vers des pages authentifiées iront à /login.aspx