Come vengono popolati OwinContext.Request.Path e PathBase?

Question

Sto scrivendo il mio middleware OWIN per il flusso del codice di autorizzazione di OpenID Connect, basato su altri esempi nel Katana Project.

Come parte di questo devo costruire un paio di URI, ad esempio un URI di reindirizzamento e un URL di ritorno.

Altri esempi di Katana fanno concatenando parti dalla richiesta corrente, ad esempio in CookieAuthenticationHandler

loginUri = 
    Request.Scheme + 
    Uri.SchemeDelimiter + 
    Request.Host + 
    Request.PathBase + 
    Options.LoginPath + 
    new QueryString(Options.ReturnUrlParameter, currentUri); 

La mia domanda è quali regole governano ciò che finisce nelle proprietà di due percorsi:

OwinContext.Request.Path 
OwinContext.Request.PathBase 

Ho provato a controllare queste proprietà mentre la richiesta passa attraverso diversi gestori nella pipeline sottostante, per la richiesta:

"https://localhost/Client/login" // Where Client is a virtual directory in IIS 

Il risultato:

• Nel gestore mappato per/login, il PathBase = "/ cliente/Login".
• Ma quando la richiesta raggiunge il metodo ApplyResponseChallengeAsync nel mio QuillCodeFlowHandler sulla via di ritorno per la stessa richiesta, PathBase = "/ Client" e Path = "/ Login".

Quindi, senza conoscere le "regole" per come vengono popolati questi valori, successivamente modificati, è difficile costruire URI che li utilizzano. Se qualcuno può spiegare, sarà molto apprezzato.

Un estratto della mia configurazione è:

app.UseCookieAuthentication(new CookieAuthenticationOptions 
{ 
    AuthenticationType = CookieAuthenticationDefaults.AuthenticationType, 
    LoginPath = new PathString("/Login") 
}); 

app.UseQuillCodeFlowAuthentication(new QuillCodeFlowOptions()); 

app.Map("/login", map => 
{ 
    map.Run(async ctx => 
    { 
    if (ctx.Authentication.User == null || 
    !ctx.Authentication.User.Identity.IsAuthenticated) 
    {       
     var authenticationProperties = new AuthenticationProperties(); 
     [...] 
     ctx.Authentication.Challenge(authenticationProperties, 
            QuillCodeFlowDefaults.AuthenticationType); 

Il OWIN specification dà qualche spiegazione e il metodo Microsoft.Owin.Host.HttpListener.GetPathAndQuery sembra essere in cui le variabili di percorso sono impostati inizialmente.

Answer 1

Quando si utilizza il costrutto

app.Map("/login", map => [...] 

Questo utilizza

Owin.MapExtensions.Map 

che costruisce un'istanza

Microsoft.Owin.Mapping.MapMiddleware 

per il codice che deve correre.

Il comportamento che ho visto è spiegato nel metodo Invoke di questo middleware:

public async Task Invoke(IDictionary<string, object> environment) 
{ 
    IOwinContext context = new OwinContext(environment); 

    PathString path = context.Request.Path; 

    PathString remainingPath; 
    if (path.StartsWithSegments(_options.PathMatch, out remainingPath)) 
    { 
     // Update the path 
     PathString pathBase = context.Request.PathBase; 
     context.Request.PathBase = pathBase + _options.PathMatch; 
     context.Request.Path = remainingPath; 

     await _options.Branch(environment); 

     context.Request.PathBase = pathBase; 
     context.Request.Path = path; 
    } 
    else 
    { 
     await _next(environment); 
    } 
} 

In pratica il codice cambia il percorso e PathBase prima si corre il delegato (attendere _options.Branch (ambiente)) , quindi riporta questi ai valori originali dopo l'esecuzione di completata.

Quindi il comportamento che ho visto è spiegato.