web-dev-qa-db-fra.com

Le nouveau projet Asp.Net MVC5 produit une boucle infinie pour la page de connexion

Je crée un nouveau projet avec Visual Studio 2013, je choisis Asp.Net MVC et le framework 4.5.1 Le projet est créé. Je ne fais rien d'autre que F5 pour démarrer la page Web par défaut. Malheureusement, il produit une redirection vers la page de connexion qui redirige également vers la page de connexion. Voici une version courte de l'URL que j'ai dans le navigateur:

http://localhost:5285/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FAccount%2525252FLogin%2525253FReturnUrl%2525253D%252525252FAccount%252525252FLogin%252525253FReturnUrl%252525253D%25252525252FAccount%25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FAccount%2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525

Je n'ai aucune erreur dans l'observateur d'événements. Mais sur l'écran je vois: 

"Erreur HTTP 404.15 - Introuvable Le module de filtrage des demandes est configuré pour Être configuré pour refuser une demande lorsque la chaîne de requête est trop longue."

Le site Web est en cours d'exécution avec le paramètre par défaut dans IIS Express. Comment puis-je résoudre ce problème? Je suppose que quelque chose ne va pas avec mon Visual Studio 2013?

Modifier

Cela fonctionne si je crée un nouveau site Web et que je l’héberge dans IIS. Mais si je crée un nouveau site Web (sans rien modifier) ​​et que je clique simplement sur play (qui démarre IIS Express par défaut), ce n'est pas le cas.

Modifier 2

J'ai supprimé tous les sites Web dans le dossier Documents\IISExpress\config\applicationhost.config. J'ai tout recompilé, et il a créé cette entrée:

    <siteDefaults>
        <logFile logFormat="W3C" directory="%IIS_USER_HOME%\Logs" />
        <traceFailedRequestsLogging directory="%IIS_USER_HOME%\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" />
    </siteDefaults>
    <applicationDefaults applicationPool="Clr4IntegratedAppPool" />
    <virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>

Je reçois toujours l'erreur avec IIS Express, pas avec IIS.

asp.netasp.net-mvcvisual-studio-2013asp.net-mvc-5
73
Patrick Desjardins

Veuillez noter qu'il s'agit d'un conseil potentiellement dangereux, car il est rarement conseillé de modifier directement un fichier de configuration d'applicationhost. Certains outils le feront pour vous, en toute sécurité (par exemple, à partir de Visual Studio.) Avant de poursuivre, veillez à créer une copie de sauvegarde de ce fichier au cas où votre IIS Express serait mis à la corbeille.

Pour résoudre ce problème, j'ai pris le fichier de configuration par défaut IIS situé ici: 

C:\Windows\System32\inetsrv\config\applicationHost.config

À mon document

%userprofile%\documents\iisexpress\config\applicationhost.config

Et ça a fonctionné. 

C'était parce que j'avais un ensemble d'authentification Windows et non le compte anonyme.

1
Patrick Desjardins

Mettez en surbrillance le projet dans Visual Studio

Ouvrez le panneau "Propriétés" à droite (ou appuyez sur F4)

Définissez 'Authentification Windows' sur 'Désactivé'

Définissez 'Authentification anonyme' sur 'Activé'

62
RobA2345

Ce problème est dû au mode d'authentification sélectionné (par défaut) par le modèle MVC 5, ce qui déclenche le style de renvoi ReturnUrl pouvant entraîner une boucle infinie s'il n'est pas configuré correctement.

Pour désactiver la découverte de démarrage OWIN, ajoutez cette clé à votre fichier webconfig.

<add key="owin:AutomaticAppStartup" value="false"/>
35
user3573341

L'attribut [AllowAnonymous] est manquant lors de l'action de connexion.

[AllowAnonymous]
public ActionResult Login(string returnUrl)
{
    // code....
}

2e possibilité , spécifique à IIS Express uniquement: si vous avez créé plusieurs fois le même projet WebApplication1 par défaut, en jouant avec des paramètres d'authentification différents, IIS Express a enregistré des paramètres d'authentification supplémentaires dans son fichier de configuration . Quelque chose comme:

    <location path="WebApplication1">
        <system.webServer>
            <security>
                <authentication>
                    <windowsAuthentication enabled="true" />
                    <anonymousAuthentication enabled="false" />
                </authentication>
            </security>
        </system.webServer>
    </location>
</configuration>

Les configurations se trouvent dans le dossier Documents de l'utilisateur Documents\IISExpress\config\ et vous devez rechercher: 

applicationhost.config

Ensuite, supprimez simplement le noeud XML <location path="WebApplication1"> mentionné ci-dessus.

Mise à jour pour VS 2015+

Si vous utilisez Visual Studio 2015 ou une version ultérieure, vérifiez le chemin du fichier de configuration: $(solutionDir)\.vs\config\applicationhost.config

Chaque solution aura son propre fichier de configuration.

33
Nenad

Je devais enlever ( Source Link ):

<authorization>
  <deny users="?" />
</authorization>
7
Alkemichar

Je sais que je peux être en retard et ce n'est pas directement pour la question du PO. Mais si quelqu'un dans le futur vient ici, une dernière vérification à propos des attributs AllowAnonymous et Authorize est que, vous devez vérifier toutes les actions enfants aussi.

Par exemple, ma disposition (que la page de connexion utilise également) appelle 2 actions enfants pour les chapelures et la barre latérale, sans attribut AllowAnonymous (le contrôleur avait l'attribut Authorize.

J'espère que cette aide.

6
Luke Vo

Dans IIS, sélectionnez votre site Web et vérifiez l'authentification. Si vous utilisez l'authentification par formulaires, puis -

  1. Définissez 'Authentification Windows' sur 'Désactivé', 
  2. Définissez 'Authentification anonyme' sur 'Activé' 
  3. Définissez 'Authentification par formulaire' sur 'Activé'
5
Sanjay Sharma

Le modèle ASP.Net MVC 5 ajoute Microsoft.Owin et les bibliothèques associées au projet. Comme l'infrastructure d'Owin ne nécessite pas d'authentification par formulaire, le modèle introduit également la clé suivante dans web.config.

<system.webServer>
  <modules>
    <remove name="FormsAuthentication" />
  </modules>
</system.webServer>

La présence de cette clé peut être une raison pour une boucle indésirable vers la page de connexion. Le commenter peut aider à résoudre le problème pour certaines personnes.

2
A is A

J'ai rencontré le même problème parce que mon projet MVC était configuré pour .Net 4.5 mais j'utilisais .Net 4.0 comme pool d'applications dans IIS. Il est passé au pool d’applications .Net 4.5 et le problème a été résolu. J'espère que ça aidera quelqu'un d'autre!

2
Kam

Je viens de traiter cette question pendant des heures.

Pour moi, c'était dans le fichier Startup.Auth.cs.

Ce code, lorsqu'il a été commenté, a arrêté la boucle de redirection.

        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
            LoginPath = new PathString("/Account/Login")
        });
2
Nicholas V.

TL: DR? N'appelez pas une API Web protégée (toute API nécessitant une autorisation) à partir d'une page d'autorisation telle que ~/Account/Login (qui, par elle-même, ne le fait PAS). Si vous le faites, vous entrerez dans une boucle de redirection infinie côté serveur.

Cause

J'ai trouvé que le coupable était, indirectement, AccountController::Authorize et que AccountController est décoré avec [Authorize]. 

La cause principale était l'appel de Sammy () à partir de HomeViewModel () (ligne 6 de home.viewmodel.js), qui accédait à une "API Web protégée". Cette opération était en cours pour/Account/Login, ce qui a entraîné une redirection vers/Account/Login.

Confirmation

Vous pouvez confirmer que c'est la cause de votre problème de plusieurs manières:

  1. Décorer AccountController::Authorize avec [AllowAnonymous]
  2. Mettez en commentaire les appels Sammy () passés lors de la construction de viewmodel.

Solution

La solution consistait à n'émettre l'ensemble d'applications (a.k.a "~/bundles/app") que pour les vues nécessitant déjà une autorisation. A ma connaissance, les comptes/vues sont des vues classiques basées sur MVC et ne font pas partie du modèle de données de l'application/viewmodel, mais j'avais déplacé par erreur l'appel bundle Scripts.Render(@"~/bundles/app") dans _Layout.cshtml (provoquant ainsi des appels d'API Web protégés pour tous les MVC). vues, y compris/Compte /.)

2
Shaun Wilson

dans mon cas: dans mon _layout.cshtml, j'utilise Html.Action pour appeler une action à partir du contrôleur d'autorisation: ex: Html.Action ("Count", "Product") -> erreur de boucle

correctif: décorer par l'attribut [AllowAnonymous] de cette action (ou supprimer ces utilitaires HTML de _layout)

2
TienQuang

Assurez-vous qu'aucune action en cours dans le pipeline ne possède l'attribut authorize . Dans mon cas, ma présentation avait un contrôleur de menu de navigation qui manquait de l'attribut allowAnonymous.

1
Kalyan

Ces réponses sont plus ou moins des pièces du même puzzle; Je vais essayer de tout mettre au même endroit… .. Le problème décrit par OP touche mon application dès que j'ai implémenté le pipeline OWIN et AspNET Identity.

Voyons donc comment résoudre ce problème ...

  1. OWIN Startup

J'imagine que vous en avez besoin, car si vous n'en avez pas, vous n'avez pas besoin d'authentification, et j'imagine que vous en avez… .. Sauf que vous utilisez une authentification à l'ancienne, et je suppose que vous n'en avez pas. Donc, ne supprimez pas l’attribut de démarrage OWIN ...

[Assembly: OwinStartupAttribute(typeof(YourApp.Probably_App_Start.SomethingLikeAuthConfig))]

... ou la ligne de configuration ...

<add key="owin:AppStartup" value="YourApp.Probably_App_Start.SomethingLikeAuthConfig" />
  1. Restriction d'accès aux contrôleurs

Maintenant, nous avons clarifié cela, vous avez besoin de l'authentification. Cela signifie que chacun de vos contrôleurs a besoin de l'attribut [Authorize] ou que vous pouvez faire de même pour tous les contrôleurs situés au même endroit en enregistrant la chose globalement (par exemple, dans RegisterGlobalFilters(), ajoutez la ligne filter.Add(new AuthorizeAttribute())) . Dans le premier cas (lors de la sécurisation de chaque (contrôleur séparément) sautez cette partie, passez à la suivante . Dans ce dernier cas, tous vos contrôleurs seront protégés contre les accès non autorisés, vous avez donc besoin d’un point d’entrée pour cette autorisation - action non protégée Login() .. ... ajouter...

[AllowAnonymous]

... et vous devriez être bon.

  1. Configuration du cookie OWIN

Lorsque votre utilisateur se connecte, son navigateur stocke un cookie crypté (espérons-le!) Afin de simplifier les choses pour le système. Donc, vous avez besoin d'un cookie - ne supprimez pas la ligne qui dit UseCookieAuthentication.

  1. Ce que vous devez vraiment faire, c'est désactiver le mécanisme d'authentification intégré IIS pour votre application Web. Cela signifie que vous devez désactiver Windows Authentication (désactivé) et permettre à tout utilisateur d'entrer au moins aussi longtemps que IIS Express est concerné, en définissant Anonymous Authentication (activé).

Lorsque vous démarrez votre site Web, ces paramètres sont ensuite copiés dans la configuration IIS Express (applicationhost.config). Vous devriez y voir les deux lignes suivantes:

<windowsAuthentication enabled="false" />
<anonymousAuthentication enabled="true" />

  1. Vous pouvez avoir la configuration d'autorisation dans votre web.config qui dit deny users="?". Cela signifie que le sous-système d'autorisation a pour instruction d'empêcher les utilisateurs anonymes d'entrer ... .. Avec OWIN, cela fonctionne toujours comme prévu. Soit vous devez le supprimer, soit permettre à votre utilisateur anonyme d'accéder à la page de connexion en utilisant quelque chose comme ...

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

HTH

1
OzrenTkalcecKrznaric

J'ai résolu le même problème grâce à cette réponse acceptée: Boucle de redirection de connexion ASP.NET lorsque l'utilisateur ne joue pas le rôle .

Il est possible que le contrôleur contenant l'action de connexion soit décoré d'une AuthorizeAttribute (même une personnalisation) alors que l'action de connexion n'est pas décorée de l'attribut AllowAnonymous. Supprimer AuthorizeAttribute du contrôleur et ajouter AllowAnonymous à l'action de connexion peut être une solution possible.

1
silviagreen

J'ai eu des problèmes similaires où il était dans une boucle infinie lorsque vous rappelez le site Web localement. Il s'avère que lors du débogage local, il redirigeait les ports. J'ai mis à jour les numéros de port dans l'écran des propriétés du projet, mais la définition Azure est restée la même dans le projet cloud et tout a commencé à fonctionner comme prévu.

0
Steve Newton

dans mon cas c’était un problème très câblé, j’ai décoré le contrôleur domestique par un rôle inexistant. il en résulte une boucle de redirection.

0
Baouche Iqbal

J'ai eu le même problème avec mon projet Asp.Net MVC 4. Je l'ai résolu en allant à Startup.cs et en commentant la ligne pour ConfigureAuth (app)

    public void Configuration(IAppBuilder app)
    {
        //ConfigureAuth(app);
    }

Je me suis également assuré que l'authentification Windows était activée dans IIS pour mon projet et que toutes les autres options d'authentification étaient désactivées.

0
AndeeC

Pour moi, ceci s’est avéré dû à mon LoginViewModel contenant des références à des fichiers de ressources de traduction, apparemment protégés par une authentification. J'ai enlevé ces références et le problème a été résolu.

0
MichaelCleverly

Pour moi, en supprimant le bloc suivant l'a corrigé:

<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Assumer

<authentication mode="None" />
0
emragins