Das neue Projekt Asp.Net MVC5 erzeugt eine Endlosschleife für die Anmeldeseite

Markieren Sie das Projekt in Visual Studio

Öffnen Sie den Bereich "Eigenschaften" auf der rechten Seite (oder drücken Sie F4).

Setzen Sie "Windows-Authentifizierung" auf "Deaktiviert".

Setzen Sie "Anonyme Authentifizierung" auf "Aktiviert".

Dieses Problem ist auf den Authentifizierungsmodus zurückzuführen (standardmäßig), der von der MVC 5-Vorlage ausgewählt wird. Dadurch wird der ReturnUrl-Stil der Umleitung ausgelöst, der zu einer Endlosschleife führen kann, wenn er nicht ordnungsgemäß konfiguriert ist.

Fügen Sie diesen Schlüssel zu Ihrer Webconfig-Datei hinzu, um die OWIN-Starterkennung zu deaktivieren.

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

Bei der Login-Aktion fehlt das [AllowAnonymous]-Attribut.

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

2. Möglichkeit , spezifisch für IIS Express: Wenn Sie dasselbe Standardprojekt WebApplication1 mehrfach erstellt haben und mit verschiedenen Authentifizierungseinstellungen spielen, speichert IIS Express zusätzliche Authentifizierungseinstellungen in seiner Konfigurationsdatei . So etwas wie:

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

Die Konfigurationen befinden sich im Dokumentenordner Documents\IISExpress\config\ des Benutzers, und Sie sollten nach folgenden Elementen suchen: 

applicationhost.config

Dann löschen Sie einfach den oben erwähnten xml-Knoten <location path="WebApplication1">.

Update für VS 2015+

Wenn Sie Visual Studio 2015 oder höher verwenden, überprüfen Sie diesen Pfad für die Konfigurationsdatei: $(solutionDir)\.vs\config\applicationhost.config

Jede Lösung hat eine eigene Konfigurationsdatei.

Ich musste ( Source Link ) entfernen:

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

Ich weiß, dass ich zu spät komme, und dies ist nicht direkt für die OP-Frage. Wenn jedoch in der Zukunft jemand hierher kommt, ist eine weitere Prüfung des Attributs AllowAnonymous und Authorize das Ergebnis, dass alle untergeordneten Aktionen ebenfalls überprüft werden müssen.

Ich hatte zum Beispiel mein Layout (das auch die Anmeldeseite verwendet), das zwei untergeordnete Aktionen für Breadcrumbs und Seitenleiste aufruft, und sie hatten kein AllowAnonymous-Attribut (der Controller hatte das Authorize-Attribut).

Ich hoffe das hilft.

Wählen Sie in IIS Ihre Website aus und suchen Sie nach Authentifizierung. Wenn Sie die Formularauthentifizierung verwenden,

1. Setzen Sie "Windows-Authentifizierung" auf "Deaktiviert". 
2. Setzen Sie "Anonyme Authentifizierung" auf "Aktiviert". 
3. Setzen Sie "Formularauthentifizierung" auf "Aktiviert".

Die Vorlage ASP.Net MVC 5 fügt dem Projekt Microsoft.Owin und zugehörige Bibliotheken hinzu. Da die Owin-Infrastruktur keine Forms-Authentifizierung erfordert, führt die Vorlage außerdem den folgenden Schlüssel in web.config ein.

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

Das Vorhandensein dieses Schlüssels könnte ein Grund für das unerwünschte Zurückkehren zur Anmeldeseite sein. Durch das Kommentieren kann das Problem für einige Personen behoben werden.

Ich hatte das gleiche Problem, weil mein MVC-Projekt für .Net 4.5 konfiguriert war, aber .Net 4.0 als Anwendungspool in IIS verwendet wurde. Umgestellt auf .Net 4.5-Anwendungspool und das Problem wurde behoben. Ich hoffe, das hilft jemand anderem!

Ich habe mich stundenlang mit diesem Thema beschäftigt.

Für mich war es in der Datei Startup.Auth.cs.

Wenn dieser Code auskommentiert wurde, wurde die Weiterleitungsschleife gestoppt.

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

TL: DR? Rufen Sie keine geschützte Web-API (keine Web-API, für die eine Autorisierung erforderlich ist) von einer Autorisierungsseite wie ~/Account/Login (die dies alleine NICHT tut) auf. Wenn Sie dies tun, gelangen Sie auf der Serverseite in eine Endlos-Weiterleitungsschleife.

Ursache

Ich fand, dass der Täter indirekt AccountController::Authorize war und die Tatsache, dass AccountController mit [Authorize] verziert ist. 

Die Hauptursache war, dass Sammy () von HomeViewModel () (Zeile 6 von home.viewmodel.js) aufgerufen wurde, die auf eine "protected web API" zugegriffen hat. Dies wurde für/Account/Login durchgeführt, was dazu führte, dass/Account/Login auf sich selbst umgeleitet wurde.

Bestätigung

Sie können bestätigen, dass dies die Ursache Ihres Problems ist, indem Sie mehrere Methoden verwenden:

1. AccountController::Authorize mit [AllowAnonymous] verzieren
2. Kommentieren Sie die Sammy () - Aufrufe, die während der Viewmodel-Konstruktion gemacht wurden.

Lösung

Die Lösung bestand darin, das App-Bundle (a.k.a "~/bundles/app") nur für Ansichten auszugeben, für die bereits eine Autorisierung erforderlich war. Meines Wissens sind/Accounts/Views klassische MVC-basierte Views und nicht Teil des App-Datenmodells/Viewmodel, aber ich hatte den Aufruf des Bündels Scripts.Render(@"~/bundles/app") versehentlich in _Layout.cshtml verschoben (wodurch geschützte Web-API-Aufrufe für alle MVC-Aufrufe ausgeführt werden Ansichten einschließlich/Konto /.)

in meinem Fall: in meiner _layout.cshtml benutze ich Html.Action, um Action von Authorize Controller aufzurufen: Beispiel: Html.Action ("Count", "Product") -> Schleifenfehler

fix: dekoriere nach [AllowAnonymous] -Attribut in dieser Aktion (oder entferne diese Html-Helfer aus _layout)

Stellen Sie sicher, dass sich in der Pipeline keine Aktionen befinden, die über das Attribut authorize .. verfügen. In meinem Fall hatte mein Layout einen Navigationsmenü-Controller, dem das Attribut allowAnonymous fehlte.

Diese Antworten sind mehr oder weniger Teile desselben Puzzles. Ich werde versuchen, alles an einem Ort zu platzieren. Das von OP beschriebene Problem traf meine Anwendung in dem Moment, in dem ich die OWIN-Pipeline und AspNET Identity implementierte.

Also mal sehen, wie man es repariert ...

1. OWIN-Start

Ich denke, Sie brauchen es, denn wenn Sie es nicht tun, brauchen Sie keine Authentifizierung, und ich denke, Sie tun es. Abgesehen davon, dass Sie eine Authentifizierung im alten Stil verwenden, und ich denke, dass Sie dies nicht tun. Entfernen Sie daher auch nicht das Startattribut OWIN ...

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

... oder die Konfigurationszeile ...

<add key="owin:AppStartup" value="YourApp.Probably_App_Start.SomethingLikeAuthConfig" />

2. Zugriffsbeschränkung für Controller

Jetzt haben wir das geklärt, Sie brauchen die Authentifizierung. Dies bedeutet, dass entweder jeder Ihrer Controller das Attribut [Authorize] Benötigt oder dass Sie dasselbe für alle Controller an einem Ort tun können, indem Sie das Objekt global registrieren (z. B. in RegisterGlobalFilters(), Zeile filter.Add(new AuthorizeAttribute())). Im ersten Fall (wenn Sie jeden Controller separat sichern) überspringen Sie diesen Teil, und fahren Sie mit dem nächsten fort. Im letzteren Fall sind alle Ihre Steuerungen gegen unbefugte Zugriffe gesichert, sodass Sie einen Einstiegspunkt für diese Berechtigung benötigen - ungeschützte Login() Aktion. Einfach hinzufügen...

[AllowAnonymous]

... und du solltest gut sein.

3. OWIN Cookie Konfiguration

Wenn sich Ihr Benutzer anmeldet, speichert sein Browser verschlüsselte (hoffentlich!) Cookies, um die Dinge für das System zu vereinfachen. Sie benötigen also ein Cookie - löschen Sie nicht die Zeile mit der Aufschrift UseCookieAuthentication.

4. Was Sie wirklich tun müssen, ist, den IIS integrierten Authentifizierungsmechanismus für Ihre Webanwendung zu deaktivieren. Dies bedeutet, dass Sie Windows Authentication (Deaktiviert) ausschalten und jeden Benutzer mindestens hereinlassen müssen Solange IIS Express betroffen ist, setzen Sie Anonymous Authentication (Aktiviert).

Wenn Sie Ihre Website starten, werden diese Einstellungen in IIS Express configuration (applicationhost.config) Kopiert. Dort sollten Sie die folgenden zwei Zeilen sehen:

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

5. Möglicherweise haben Sie in Ihrer web.config die Berechtigungskonfiguration deny users="?". Dies bedeutet, dass das Autorisierungssubsystem angewiesen wird, anonyme Benutzer am Betreten zu hindern. Mit OWIN funktioniert dies weiterhin wie geplant. Sie müssen dies entweder entfernen oder Ihrem anonymen Benutzer den Zugriff auf die Anmeldeseite ermöglichen, indem Sie Folgendes verwenden:.

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

HTH

Ich habe das gleiche Problem dank dieser akzeptierten Antwort gelöst: ASP.NET Login Redirect Loop, wenn Benutzer nicht in der Rolle sind.

Es ist möglich, dass der Controller, der die Login-Aktion enthält, mit einer AuthorizeAttribute (sogar einer benutzerdefinierten) verziert ist, während die Login-Aktion nicht mit dem AllowAnonymous-Attribut versehen ist. Das Entfernen von AuthorizeAttribute aus dem Controller und das Hinzufügen von AllowAnonymous zur Anmeldeaktion kann eine mögliche Lösung sein.

Ich hatte ähnliche Probleme, wenn es in einer Endlosschleife war, als ich lokal auf der Website anrief. Es stellte sich heraus, dass beim lokalen Debuggen die Ports umgeleitet wurden. Ich habe die Portnummern im Bildschirm Projekteigenschaften aktualisiert, die Azure-Definition jedoch im Cloud-Projekt unverändert gelassen, und alles begann wie erwartet.

in meinem fall war es ein sehr verdrahtetes problem, ich habe den home controller nach nicht vorhandener rolle dekoriert. es kommt also zu einer Umleitungsschleife.

Ich hatte das gleiche Problem mit meinem Asp.Net MVC 4-Projekt. Ich habe es gelöst, indem ich zu Startup.cs gehe und die Zeile für ConfigureAuth (App) auskommentiere.

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

Ich habe auch sichergestellt, dass die Windows-Authentifizierung in IIS für mein Projekt aktiviert war und alle anderen Authentifizierungsoptionen deaktiviert waren.

Für mich stellte sich heraus, dass mein LoginViewModel Verweise auf Dateien mit Übersetzungsressourcen enthält, die anscheinend durch Authentifizierung geschützt sind. Ich entfernte diese Verweise und das Problem wurde gelöst.

Für mich hat Entfernen der folgende Block das Problem behoben:

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

Annehmen

<authentication mode="None" />