Die Umleitung zur Anmeldung funktioniert nicht, wenn die aktuelle URL bereits ReturnUrl enthält

Question

Einige Hintergrundinformationen:Unser Kunde wollte, dass eine Reihe von Aktionen nach Abschluss zur vorherigen Aktion zurückkehren.Wenn er sich beispielsweise in einer Listenansicht mit Objekten befand und auf die Schaltfläche „Neues Objekt erstellen“ klickte, wollte er zur Listenansicht zurückkehren, nachdem er das Formular ausgefüllt und gespeichert oder die Aktion abgebrochen hat.Wir haben es implementiert, indem wir das nachgeahmt haben ReturnUrl Verhalten, das bei unbefugten Zugriffsversuchen verwendet wird (Hinzufügen der aktuellen Adresse als URL-codierter Abfrageparameter).

Das Problem:Wenn ich nicht autorisiert bin (oder mit anderen Worten nicht angemeldet bin) und versuche, auf eine Aktion zuzugreifen, die dies erfordert, werde ich zur Anmeldeseite weitergeleitet (wie ich sollte) und die aktuelle URL wird eingegeben ReturnUrl param.Allerdings, wenn die aktuelle Adresse bereits enthält ReturnUrl Abfrageparameter, ich werde nirgendwo weitergeleitet und erhalte stattdessen eine leere Seite.Gibt es einen Grund, warum das passiert?

Das erwartete Ergebnis wäre die Weiterleitung zum Anmeldebildschirm mit der (URL-codierten Version) der aktuellen URL ReturnUrl param (unabhängig davon, ob die aktuelle URL eine eigene enthielt ReturnUrl param oder nicht)

Gibt es eine Möglichkeit, es wie erwartet zum Laufen zu bringen?Theoretisch könnte ich den Parameter „ReturnUrl“ (in meinen eigenen Aktionen) natürlich in etwas anderes umbenennen, aber wir haben einen solchen Parameter bereits an so vielen Stellen verwendet, dass das Umbenennen keine leichte Aufgabe sein wird.Außerdem verstehe ich nicht wirklich, warum das überhaupt nicht funktioniert.

P.S.Das Problem tritt nur auf, wenn ich den Parameter benenne ReturnUrl, wenn es returnUrl alles funktioniert wie es soll.

---

Bearbeiten:Diese Frage hieß zuvor:Der unbefugte Zugriff auf eingeschränkte Aktionen gibt nichts zurück, wenn die URL einen Parameter namens ReturnUrl enthält.Ich habe den Titel geändert, um das Verständnis zu erleichtern.

---

Bearbeiten:Diese Frage könnte ein Duplikat von sein Eine nicht autorisierte Anfrage leitet nicht zur Anmeldeseite mit dem Abfragezeichenfolgenparameter „returnUrl“ weiter.Ich muss weiter untersuchen, ob die dort bereitgestellte Lösung mein Problem löst oder nicht. Aktualisieren:Der Wortlaut ist ähnlich, aber das Problem ist schließlich anders, es handelt sich also nicht um ein Duplikat.

Answer 1

Es erwies sich als sehr mühsam, dies zu beheben, aber ich habe es geschafft.Auf der Suche nach dem Grund, warum die Weiterleitung zur Anmeldung bei einigen URLs fehlschlägt, musste ich mir eine wichtige Frage beantworten.Was ist eigentlich für die Umleitung verantwortlich und wie kann ich das außer Kraft setzen?

Das Der Artikel hat mich auf den richtigen Weg gebracht (die Sache, die für die Weiterleitung verantwortlich war, war die [Authorize] Filter) und ich begann nach einer Lösung zu suchen.Nach ein wenig Suchen habe ich es gefunden Das einfacher benutzerdefinierter Autorisierungsfilter.Natürlich hat es nicht sofort das getan, was ich wollte (und was ich im Grunde möchte, ist, dass Authorize wie gewohnt funktioniert, aber bei URLs, die enthalten, nicht kaputt geht ReturnUrl param), also habe ich den Code geändert und Folgendes erhalten:

public class Authorize2 : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        // 1. Get the default login url that was declared in web.config
        string returnUrl = FormsAuthentication.LoginUrl;
        // 2. Append current url as a return url to the login url
        returnUrl += "?ReturnUrl=" + HttpUtility.UrlEncode(HttpContext.Current.Request.Url.PathAndQuery);
        // 3. ...
        // 4. Profit
        filterContext.Result = new RedirectResult(returnUrl);
    }
}

Nachdem ich diesen Code geschrieben hatte, verbrachte ich eine weitere Stunde damit, herauszufinden, warum er nicht funktioniert (Haltepunkte innerhalb von HandleUnauthorizedRequest wurden nie getroffen).Dann habe ich es gefunden Das Website und es ergab plötzlich einen Sinn.Ein Kollege von mir hat eine globale hinzugefügt Authorize Filtern Sie aus irgendeinem Grund auf alle Aktionen und mein eigener benutzerdefinierter Filter wurde nie aufgefordert, etwas zu autorisieren (\App_Start\FilterConfig.cs).Nachdem ich diese Zeile entfernt hatte (ich muss irgendwann meinen benutzerdefinierten Filter an ihre Stelle setzen), funktionierte der obige Code wie ein Zauber.

In gewisser Weise ist die Frage noch offen, ich meine, es ist immer noch ein Rätsel, warum die Autorisierung für diese URLs fehlschlägt.Die Antwort auf diese Frage liegt zweifellos darin System.Web.Mvc.AuthorizeAttribute Quellcode, aber im Moment bin ich damit zufrieden, dass er einfach richtig funktioniert.