Reindirizzare al login non funziona se l'URL corrente contiene già il ritorno

Question

Alcuni sfondo: Il nostro cliente voleva un numero di azioni da tornare all'azione precedente quando è stata eseguita. Ad esempio, se fosse su una vista elenco di oggetti e ha fatto clic sul pulsante "Crea nuovo oggetto", voleva tornare alla vista elenco dopo aver riempito e salva il modulo o dopo aver annullato l'azione. L'abbiamo implementato imitando il comportamento ReturnUrl che viene utilizzato con tentativi di accesso non autorizzati (aggiungendo l'indirizzo corrente come parametro di query codificato dall'URL).

Il problema: Se non sono autorizzato (o in altre parole non connesso) e prova ad accedere a un'azione che richiede che venga reindirizzato alla pagina di accesso (come dovrei) e l'URL corrente viene inserito nel parametro ReturnUrl. Tuttavia, quando l'indirizzo corrente contiene già il param ReturnUrl Query, non sono reindirizzato da nessuna parte e invece ottengo una pagina vuota. C'è qualche ragione per cui questo accade?

Il risultato atteso verrebbe reindirizzato alla schermata di accesso con la (versione codificata URL di) URL corrente inserita nel parametro ReturnUrl (indipendentemente dal fatto che l'URL corrente contenesse il proprio parametro ReturnUrl)

C'è un modo per farlo funzionare come previsto? Sicuro in teoria potrei rinominare il param "returnturl" (nelle mie azioni) a qualcos'altro, ma abbiamo usato tale parametro in tanti posti già che la rinominamento non sarà un compito facile. Inoltre, non capisco il motivo per cui questo non funziona in primo luogo.

P.S. Il problema si verifica solo se nomina il parametro ReturnUrl, se è returnUrl tutto funziona come dovrebbe.

---

.

Modifica: questa domanda è stata precedentemente chiamata: accesso non autorizzato alle azioni limitato non ritorna nulla se l'URL contiene il parametro chiamato Tornall. Ho cambiato il titolo per renderlo più facile da capire.

---

.

Modifica: questa domanda potrebbe essere un duplicato di La richiesta non autorizzata non reindirizza la pagina di accesso con il parametro della stringa di query di ritorno . Dovrò indagare ulteriormente se la soluzione fornita a risolvere il mio problema o meno. Aggiornamento: la formulazione è simile, ma il problema è diverso dopo tutto, quindi non è un duplicato.

Answer 1

Questo ha dimostrato un grave dolore da risolvere, ma sono riuscito a farlo. Nella ricerca di trovare perché il reindirizzamento del login non riesce per alcuni URL che ho dovuto rispondere a me stesso una domanda importante. Cosa è effettivamente responsabile di fare il reindirizzamento e come posso ignorare questo?

Questo articolo mi ha messo in pista (la cosa responsabile del reindirizzamento è stato il filtro [Authorize]) e ho iniziato a cercare una soluzione. Dopo un po 'di ricerca ho trovato Questo filtro di autorizzazione personalizzato semplice. Ovviamente non ha fatto ciò che voglio fuori dalla scatola (e ciò che voglio è fondamentalmente per autorizzare il lavoro come normalmente ma non di interrompere gli URL che contengono parametro ReturnUrl), quindi ho modificato il codice e ho ottenuto questo: .

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);
    }
}

.

Dopo aver scritto questo pezzo di codice, ho passato un'altra ora cercando di capire perché non funziona (i punti di interruzione all'interno del HandleUnauthorizedRequest non sono mai stati colpiti). Poi ho trovato questo < / a> sito e improvvisamente aveva senso. Un collega del mio ha aggiunto un filtro globale Authorize a tutte le azioni per qualsiasi motivo e il mio filtro personalizzato non è mai stato chiesto di autorizzare nulla ( \ app_start \ FilterConfig.cs ). Dopo aver rimosso quella linea (dovrò mettere il mio filtro personalizzato alla fine), il codice sopra ha funzionato come un fascino.

In un modo che la domanda è ancora aperta, voglio dire che è ancora un mistero perché autorizzare fallisce per quegli URL. La risposta a questa domanda si trova indubbiamente nel codice sorgente System.Web.Mvc.AuthorizeAttribute, ma per ora sono soddisfatto di averlo soddisfatto giusto.