RedirectToAction leer Cookie verursacht vor Cookie gesetzt werden mit den Werten, die Ergebnisse in Cookie „verloren“
-
08-10-2019 - |
Frage
Ich bin mit einem Cookie und wenn das Cookie gesetzt ist, leitet der Benutzer zu signin, sonst zeigt sie ihnen eine Fehlerseite (unberechtigte). Das Cookie wird richtig eingestellt, und wenn ich zu einer Seite navigieren, indem Sie ihn in der Adressleiste eingeben, funktioniert es ganz gut. Allerdings, wenn ich RedirectToAction oder FormsAuthentication.RedirectToLogin das Cookie verwenden ist nicht verfügbar, die eine Endlosschleife in Umleitung verursacht.
Startseite -. Wenn der Benutzer Cookie hat, zu signin gehen, wenn sie nicht zu Hause Seite anzeigen
Signin - Wenn Benutzer Cookie, zeigen Seite, sonst Umleitung zu Hause
Meine Umleitung durch ein Attribut behandelt wird.
public sealed class RequireBillerAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
IUserSession session = ServiceLocator.Locate<IUserSession>();
if (session.BillerId == 0)
filterContext.Result = new RedirectResult("~/");
}
}
My Home Aktion wie folgt aussieht
public ActionResult Index()
{
//if the user is signed in, send them to their account page. They don't need to see the front page
if (Request.IsAuthenticated)
{
return RedirectToAction("Index", "Account");
}
//users with their cookie set should sign in
if (session.BillerId != 0)
return RedirectToAction("Index", "SignIn");
return View();
}
Und meine signin Aktion sieht wie folgt aus
[RequireBiller]
public ActionResult Index()
{
SignInModel model = BuildSignInModel();
return View(model);
}
Nun, wenn ich mysite.com/ traf die Umleitung führt zu einer Endlosschleife. In Debuggen kann das Attribut nicht den Wert aus dem Cookie finden. Das Cookie ist in der Anforderung tatsächlich leer. Als ich mysite.com/signin alles funktioniert prima geben. Irgendwelche Ideen?
Bearbeiten
Wie bereits angedeutet, lief ich Fiedler. Hier ist, was die Anforderungen aussehen
# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
1 302 HTTP localhost:27412 / 124 private text/html; charset=utf-8 chrome:6008
2 302 HTTP localhost:27412 /SignIn 118 private text/html; charset=utf-8 chrome:6008
3 302 HTTP localhost:27412 / 124 private text/html; charset=utf-8 chrome:6008
4 302 HTTP localhost:27412 /SignIn 118 private text/html; charset=utf-8 chrome:6008
Und hier ist die Cookie-Informationen
Erste
__ __ RequestVerificationToken_Lw = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Zweite
4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * =; __RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Dritte
__ __ RequestVerificationToken_Lw = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Vierte
4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * =; __RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Und hier ist, wie es aussieht, wenn ich schreibe in / signin in die Adressleiste
__ __ RequestVerificationToken_Lw = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Ja, meine Cookies verschlüsselt. Die cookie ist „4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc *“ Mir scheint, die Umleitung wird in ein neues leeres Cookie anhängt. WARUM? Ich bin nicht sicher.
ZUSATZ gibt es 3 Cookies in der Anfrage nach dem Debuggen, habe ich, dass in der Tat gefunden. Die erste ist die leere Cookie, das standardmäßig zurückgegeben wird, wenn Sie den Namen verwenden. Der dritte Cookie in der Sammlung hat die eingestellten Werte. Warum wird dieses Cookie in die Anfrage angehängt ist ein Rätsel. Ich kann wahrscheinlich arbeiten, um dieses durch die Cookie Kommissionierung, die einen Wert über die anderen, aber ich würde lieber die Wurzel Problem beheben, was auch immer es ist, die nur auf der Anmeldeseite geschieht.
Lösung
Ich denke, was passiert ist, dass RedirectToAction eine Response.Redirect tut (), die die Bearbeitung der Anfrage wird beendet und nicht so dass das Cookie gesetzt werden. Klingt wie ein ähnliches Problem zu dem, was dokumentiert ist hier für die Sitzung:
http://weblogs.asp.net/bleroy/ Archiv / 2004/08/03 / 207486.aspx
Andere Tipps
hatte ich ein Cookie, das nicht gesetzt wurde ordnungsgemäß nach RedirectToAction () aufrufen. Ich landete unter Verwendung TempData [] wie in dieser Antwort beschrieben: https://stackoverflow.com/a/3624353/1265197
Hier ist mein Code. Das Konto Zeichenfolge wurde über eine Abfrage-String in der URL namens ‚Konto‘ Introduction:
public ActionResult OriginatingAction(string account)
{
//Some other code
TempData["data"] = account;
return RedirectToAction("RedirectAction");
}
Ich konnte dann TempData [ „Daten“] verwenden, um die Cookie in Aktion zu setzen, dass ich umgeleitet:
public ActionResult RedirectAction()
{
if(TempData["data"] != null)
{
HttpCookie dataCookie = new HttpCookie("dataCookie");
dataCookie.Values.Add("account", TempData["data"] as string);
dataCookie.Expires = DateTime.Now.AddHours(12);
Response.Cookies.Add(dataCookie);
}
return View();
}