Dove si trova il punto di ingresso per HttpContext di ASP.NET MVC?

Aggiornamento:

Con ulteriori approfondimenti mi sono imbattuto in Cephas L'eccellente articolo di Lin e il PDF del ciclo di vita di ASP.NET MVC 5 .

Il PDF contiene due immagini che illustrano chiaramente il flusso del ciclo di vita di MVC 5. Il primo dà una prospettiva di 10.000 piedi di tutto questo. La seconda immagine è molto dettagliata e troppo grande per essere condivisa qui.

La prima immagine:

Lamiasoluzionealternativa:

Dopoaverfattounpo'discavo,homessoinsiemeunpo'disoluzione.Duefiltridiautorizzazionechevengonoeseguitiindiversiordini.

IfiltriMVChannounordineoperativobasatosullarispostadiErangaaquestadomanda: link

Eranga wrote:

Filters run in the following order:

1. Authorization filters
2. Action filters
3. Response filters
4. Exception filters

For example, authorization filters run first and exception filters run last. Within each filter type, the Order value specifies the run order. Within each filter type and order, the Scope enumeration value specifies the order for filters. This enumeration defines the following filter scope values (in the order in which they run):

1. First
2. Global
3. Controller
4. Action
5. Last

Extracted from MSDN

Con questa conoscenza, ho implementato un secondo attributo Authorization LoadAuthCookie che gestisce il caricamento del cookie, recuperando i dati rilevanti relativi al ruolo / permessi dell'utente corrente in un IPrincipal e IIdentity personalizzato e assegnando l'utente corrente di HttpContext a questo IPrincipal.

L'attributo LoadAuthCookie carica solo i dati del cookie se esiste e non gestisce il reindirizzamento o qualsiasi altra logica di autorizzazione ed è registrato all'interno di RegisterGlobalFilters .

A partire da Global.asax:

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        /* other global stuff */
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        /* other global stuff */
    }
}

E poi

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new LoadAuthCookie());
}

Questo registra l'attributo LoadAuthCookie non solo prima, ma anche con un ordine di operazione superiore rispetto agli altri attributi di autorizzazione.

Quindi il mio altro attributo Authorization, CustomAuthorize , può essere applicato a livello Controller / Azione e si attiva sempre dopo che il cookie auth è stato caricato, quindi ha accesso a tutte le cose carine nell'IPrincipal personalizzato.

[CustomAuthorize(Role=Role.Admin)]
public class AdminController : ControllerBase
{
    public ActionResult Index()
    {
        return View();
    }
}

Tuttavia questo probabilmente non è l'ideale, e un filtro di autenticazione personalizzato sarà il posto in cui caricare il cookie di autenticazione, invece di un filtro di autorizzazione personalizzato. L'autenticazione avviene prima dell'autorizzazione.

Se ciò fosse raccomandato, non ci sarebbe AuthorizeAttribute e non sarebbe una classe non sigillata.

Anche se non si può scherzare con esso - e non è possibile - il peggior risultato è il fatto che ogni HttpContext occupa molta memoria. Controllare se un elemento esiste nel dizionario della sessione è una caduta in un bucket per la versione corrente di ASP.NET.

NancyFX ospitato autonomamente e ASP.NET MVC 6 hanno effettivamente affrontato alcune di queste sfide. Entrambi sono liberi di utilizzare HttpContext se si sceglie di non ospitare su IIS. È possibile trovare le pipeline di NancyFX e la mancanza di HTTPContext più piacevole e performante di quello che si sta facendo in ASP.NET.