RedirectToAction causando biscotto vuoto da impostare prima del cookie con valori, che si traduce in “Lost” cookie
-
08-10-2019 - |
Domanda
Sto usando un biscotto e se il cookie è impostato, in avanti l'utente a signin, altrimenti mostra loro una pagina di errore (non autorizzata). Il cookie è stato impostato correttamente, e se ci si dirige verso qualsiasi pagina digitandolo nella barra degli indirizzi, funziona bene. Tuttavia, quando uso RedirectToAction o FormsAuthentication.RedirectToLogin il cookie non è disponibile, che sta causando un ciclo infinito di reindirizzamento.
casa -. Se l'utente ha dei cookie, andare al signin, se non una home page
Signin - Se l'utente ha dei cookie, spettacolo pagina, altrimenti reindirizzamento alla home
Il mio redirezione è gestita attraverso un attributo.
public sealed class RequireBillerAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
IUserSession session = ServiceLocator.Locate<IUserSession>();
if (session.BillerId == 0)
filterContext.Result = new RedirectResult("~/");
}
}
La mia casa sembra d'azione come questo
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();
}
E i miei signin sguardi d'azione come questo
[RequireBiller]
public ActionResult Index()
{
SignInModel model = BuildSignInModel();
return View(model);
}
Ora, quando ho colpito mysite.com/ il reindirizzamento causa un ciclo infinito. In debug, l'attributo non riesce a trovare il valore dal cookie. Il cookie è in realtà vuoto nella richiesta. Quando digito mysite.com/signin tutto funziona peachy. Tutte le idee?
Modifica
Come suggerito, mi sono imbattuto violinista. Ecco quello che le richieste sembrano
# 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
Ed ecco le informazioni del cookie
Prima
__ RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Secondo
4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * =; __RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
In terzo luogo
__ RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
In quarto luogo
4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * =; __RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Ed ecco come si presenta quando si digita in / signin nella barra degli indirizzi
__ RequestVerificationToken_Lw __ = NNu8v2oTMX2YKQOW + JRN1LQRYPhlmPszQa8Rs1KrQp1pPxWmQO8GG7eRrzbhFZF38p05ckuLHAK3QaTIlxeFJ6POTX1woXRx / ahApLpF529inJO9mj3jSnoHqG6fthzJpoLYQL61NOCCUO2wwzLmQg ==; 4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc * = P% 2ffJD5CdLO0pCGU6GntaPw * = P6QAytlDVUrkQn84c9vDVg *
Sì, i miei cookie sono criptate. Il cookiename è "4% 40f0nkyBbqcTD4g9yl1J8KDNcWdqRpixrEoHLuMP2Lc *" Mi sembra il reindirizzamento sta aggiungendo un nuovo cookie vuoto in là. PERCHÉ? Non sono sicuro.
ULTERIORI Dopo il debug, ho trovato che in effetti ci sono 3 i cookie nella richiesta. Il primo è il cookie vuoto, che viene restituito per default quando si utilizza il nome. Il terzo cookie nella collezione ha il set valori. Perché è questo cookie aggiungendo nella richiesta è un mistero. Probabilmente posso ovviare a questo con la scelta il cookie che ha un valore sopra l'altra, ma preferirei risolvere il problema di fondo, qualunque essa sia, che sta accadendo solo sulla pagina di accesso.
Soluzione
Credo che quello che sta succedendo è che RedirectToAction sta facendo un Response.Redirect (), che è terminato l'elaborazione della richiesta e non permettendo il cookie da impostare. Suona come un problema simile a quello che è documentato qui per la sessione:
http://weblogs.asp.net/bleroy/ archive / 2004/08/03 / 207486.aspx
Altri suggerimenti
Ho avuto un cookie che non veniva impostato correttamente dopo aver chiamato RedirectToAction (). Ho finito per utilizzando TempData [] come descritto in questa risposta: https://stackoverflow.com/a/3624353/1265197
Ecco il mio codice. La stringa di account è stato recuperato tramite una stringa di query sull'URL chiamato 'conto':
public ActionResult OriginatingAction(string account)
{
//Some other code
TempData["data"] = account;
return RedirectToAction("RedirectAction");
}
I potrebbe quindi utilizzare TempData [ "data"] per impostare il cookie nell'azione che mi ridiretti su:
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();
}