Das neue Asp.Net MVC5-Projekt erzeugt eine Endlosschleife zur Anmeldeseite

Ich erstelle ein brandneues Projekt mit Visual Studio 2013, wähle Asp.Net MVC und das Framework 4.5.1. Das Projekt wird erstellt. Dann mache ich nichts anderes als F5, um die Standardwebseite zu starten. Leider wird eine Weiterleitung zur Anmeldeseite erstellt, die auch zur Anmeldeseite umgeleitet wird. Hier ist eine kurze Version der URL, die ich im Browser habe:

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

Ich habe keinen Fehler in der Ereignisanzeige. Aber auf dem Bildschirm sehe ich:

"HTTP-Fehler 404.15 - Nicht gefunden Das Anforderungsfiltermodul ist so konfiguriert, dass eine Anforderung abgelehnt wird, bei der die Abfragezeichenfolge zu lang ist."

Die Website wird mit der Standardeinstellung in IIS Express ausgeführt. Wie kann ich dieses Problem beheben? Ich vermute, dass etwas mit meinem Visual Studio 2013 nicht stimmt.

Bearbeiten

Es funktioniert, wenn ich eine brandneue Website erstelle und sie in IIS hoste. Wenn ich jedoch eine neue Website erstelle (ohne etwas zu ändern) und einfach auf Wiedergabe drücke (wodurch IIS Express standardmäßig gestartet wird), ist dies nicht der Fall.

Bearbeiten 2

Ich habe alle Websites in der Datei "Documents \ IISExpress \ config \ applicationhost.config" gelöscht . Ich habe alles neu kompiliert und es hat diesen Eintrag erstellt:

    <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>

Ich erhalte immer noch den Fehler mit IIS Express, nicht mit IIS.

Markieren Sie das Projekt in Visual Studio

Öffnen Sie das Fenster "Eigenschaften" rechts (oder drücken Sie F4).

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

Setzen Sie "Anonyme Authentifizierung" auf "Aktiviert".

Bei der Anmeldeaktion fehlt ein [AllowAnonymous]Attribut.

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

2. Möglichkeit , nur für IIS Express spezifisch: Wenn Sie dasselbe Standardprojekt WebApplication1mehrmals erstellt haben und mit unterschiedlichen Authentifizierungseinstellungen spielen, hat IIS Express zusätzliche Authentifizierungseinstellungen in der Konfigurationsdatei gespeichert. 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 Ordner "Dokumente" des Benutzers. Documents\IISExpress\config\Sie sollten Folgendes suchen:

applicationhost.config

Dann löschen Sie einfach den <location path="WebApplication1">oben genannten XML-Knoten .

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 verfügt über eine eigene Konfigurationsdatei.

Dieses Problem ist auf den von der MVC 5-Vorlage (standardmäßig) ausgewählten Authentifizierungsmodus zurückzuführen, der den ReturnUrl-Umleitungsstil auslöst, der bei nicht korrekter Konfiguration zu einer Endlosschleife führen kann.

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

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

Ich musste entfernen ( Source Link ):

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

Ich weiß, dass ich möglicherweise zu spät komme, und dies ist nicht direkt für die Frage des OP. Aber wenn in Zukunft jemand hierher kommt, ist eine weitere Überprüfung AllowAnonymousund AuthorizeAttribut, dass Sie auch alle untergeordneten Aktionen überprüfen müssen .

Zum Beispiel hatte ich mein Layout (das auch auf der Anmeldeseite verwendet wird), das zwei untergeordnete Aktionen für Breadcrumbs und die Seitenleiste aufruft, und sie hatten kein AllowAnonymousAttribut (der Controller hatte ein AuthorizeAttribut).

Ich hoffe das hilft.

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

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

Die ASP.Net MVC 5-Vorlage fügt dem Projekt Microsoft.Owin und verwandte Bibliotheken hinzu. Da für die Owin-Infrastruktur keine Formularauthentifizierung erforderlich ist, wird in der Vorlage auch der folgende Schlüssel in web.config eingeführt.

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

Das Vorhandensein dieses Schlüssels kann ein Grund für eine unerwünschte Rückschleife zur Anmeldeseite sein. Das Kommentieren kann bei manchen Menschen helfen, das Problem zu beheben.

Ich hatte das gleiche Problem, weil mein MVC-Projekt für .Net 4.5 konfiguriert war, ich jedoch .Net 4.0 als Anwendungspool in IIS verwendete. Es wurde auf den .Net 4.5-Anwendungspool umgestellt und das Problem wurde behoben. Ich hoffe das hilft jemand anderem!

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

Ursache

Ich fand, dass der Schuldige indirekt war AccountController::Authorizeund die Tatsache, dass AccountControllermit geschmückt ist [Authorize].

Die Hauptursache war, dass Sammy () von HomeViewModel () (Zeile 6 von home.viewmodel.js) aufgerufen wurde, das auf eine "geschützte Web-API" zugegriffen hat. Dies wurde für / Account / Login durchgeführt, was dazu führte, dass / Account / Login zu sich selbst umleitete.

Bestätigung

Sie können anhand verschiedener Methoden bestätigen, dass dies die Ursache Ihres Problems ist:

1. Schmücken AccountController::Authorize Sie mit[AllowAnonymous]
2. Kommentieren Sie die Sammy () -Aufrufe aus, die während der Erstellung des Ansichtsmodells ausgeführt wurden.

Lösung

Die Lösung bestand darin, das App-Bundle (auch bekannt als "~ / bundles / app") nur für Ansichten auszugeben, für die bereits eine Autorisierung erforderlich war. Meines Wissens sind / Account / Views klassische MVC-basierte Views und nicht Teil des App-Datenmodells / Viewmodels, aber ich habe den Bundle- Scripts.Render(@"~/bundles/app")Aufruf fälschlicherweise in _Layout.cshtml verschoben (wodurch geschützte Web-API-Aufrufe für alle MVC-Views verursacht wurden) , einschließlich / Account /.)

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

Fix: Dekorieren Sie mit dem Attribut [AllowAnonymous] in dieser Aktion (oder entfernen Sie diesen HTML-Helfer aus _layout).

Ich habe mich nur stundenlang mit diesem Thema befasst.

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

Wenn dieser Code auskommentiert wurde, stoppte er die Umleitungsschleife.

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

Bitte beachten Sie, dass dies potenziell schädliche Ratschläge sind. Es ist selten eine gute Idee, eine Anwendungshost-Konfigurationsdatei direkt zu ändern. In der Regel gibt es Tools, die dies sicher für Sie erledigen (z. B. in Visual Studio). Bevor Sie fortfahren, stellen Sie sicher um eine Sicherungskopie dieser Datei für den Fall zu erstellen, dass Ihr IIS Express in den Papierkorb verschoben wird.

Um dieses Problem zu beheben, habe ich die Standard-IIS-Konfigurationsdatei verwendet, die sich hier befindet:

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

Zu meinem Dokument

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

Und es hat funktioniert.

Dies lag daran, dass ich eine Windows-Authentifizierung festgelegt hatte und nicht das anonyme Konto.

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

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 Anmeldeaktion enthält, mit einem AuthorizeAttribute(sogar einem benutzerdefinierten) Element versehen ist, während die Anmeldeaktion nicht mit einem AllowAnonymousAttribut versehen ist. Das Entfernen AuthorizeAttributevom Controller und das Hinzufügen AllowAnonymouszur Anmeldeaktion kann eine mögliche Lösung sein.

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 implementiert habe.

Mal sehen, wie man das Problem behebt ...

1. OWIN Startup

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, Sie tun dies nicht. Entfernen Sie also auch nicht das OWIN-Startattribut ...

[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

Nachdem wir dies geklärt haben, benötigen Sie die Authentifizierung. Dies bedeutet, dass entweder jeder Ihrer Controller das [Authorize]Attribut benötigt, oder Sie können dasselbe für alle Controller an einem Ort tun, indem Sie das Objekt global registrieren (z. B. in RegisterGlobalFilters(), Zeile hinzufügen filter.Add(new AuthorizeAttribute())). Im ersteren Fall (wenn Sie jeden Controller separat sichern) überspringen Sie diesen Teil, fahren Sie einfach mit dem nächsten fort. Im letzteren Fall sind alle Ihre Controller gegen unbefugten Zugriff geschützt Login(). Sie benötigen daher einen Einstiegspunkt für diese Autorisierung - ungeschützte 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 integrierten IIS-Authentifizierungsmechanismus für Ihre Webanwendung zu deaktivieren. Dies bedeutet, dass Sie deaktivieren Windows Authentication(Deaktiviert) und aktivieren, dass jeder Benutzer, zumindest solange es sich um IIS Express handelt, durch Aktivieren Anonymous Authentication(Aktiviert) zugelassen wird.

Wenn Sie Ihre Website starten, werden diese Einstellungen wiederum in die IIS Express-Konfiguration ( applicationhost.config) kopiert. Dort sollten folgende zwei Zeilen angezeigt werden:

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

5. Möglicherweise befindet sich in Ihrer web.config die Berechtigungskonfiguration, die besagt deny users="?". Dies bedeutet, dass das Autorisierungssubsystem angewiesen wird, die Eingabe anonymer Benutzer zu verhindern. Mit OWIN funktioniert dies immer noch 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 hatte ähnliche Probleme, bei denen es sich um eine Endlosschleife handelte, als ich lokal auf die Website zurückrief. Es stellt sich heraus, dass beim lokalen Debuggen die Ports umgeleitet wurden. Ich habe die Portnummern im Bildschirm mit den Projekteigenschaften aktualisiert, aber die Azure-Definition im Cloud-Projekt unverändert gelassen, und alles begann wie erwartet zu funktionieren.

Ich hatte das gleiche Problem mit meinem Asp.Net MVC 4-Projekt. Ich habe es behoben, indem ich zu Startup.cs gegangen bin und die Zeile für ConfigureAuth (App) auskommentiert habe.

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

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

Für mich stellte sich heraus, dass mein LoginViewModel Verweise auf Übersetzungsressourcendateien enthält, die offenbar durch Authentifizierung geschützt sind. Ich habe diese Referenzen entfernt und das Problem wurde gelöst.

Für mich hat das Entfernen des folgenden Blocks das Problem behoben:

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

Annehmen

<authentication mode="None" />

In meinem Fall war es ein sehr verdrahtetes Problem. Ich habe den Home-Controller nach einer nicht existierenden Rolle dekoriert. es verursacht also eine Umleitungsschleife.

Gehen Sie zu Ihrer Datei applicationhost.config und setzen Sie anonymauthentication = "true".

<authentication>

            <anonymousAuthentication enabled="true" userName="" />
            <windowsAuthentication enabled="true">
                <providers>
                    <add value="Negotiate" />
                    <add value="NTLM" />
                </providers>
            </windowsAuthentication>

        </authentication>