Záznam ze Vzdělávacího okénka HAVIT ze 7. června 2018, kde Mirek Holec prezentoval přehled ASP.NET Razor Pages:
Nahrávka je publikována na našem HAVIT YouTube Channelu.
Záznam ze Vzdělávacího okénka HAVIT z 3. května 2018, kde Miroslav Holec prezentoval historii [ASP].NET Core a chystaných novinkách ve verzi 2.1. Nahrávka je publikována na našem HAVIT YouTube Channelu.
Textovou podobu informací najdete na Mirkovo blogu:
V rámci solution máme dva webové projekty – Web (javascriptová single-page aplikace) a WebAPI (backend s API). v ASP.NET Core 2.0. Řešili jsme problém, že nám nefungoval spolehlivě CORS – javascriptové requesty z Webu nedostávaly správné odpovědi od WebAPI. Chovalo se to velmi podivně i přesto, že lokálně vše fungovalo, a to i když aplikace běžely na různých portech.
Konkrétně:
CORS v aplikaci máme nastaven celkem standardně a nepříliš restriktivně:
Kde byl(y) problém(y):
Nejdříve jsme neměli povolené všechny hlavičky (pozor zejména na Authorization, která není v Chrome Developer tools defaultně vidět). Nakonec jsme stejně skočili u AllowAnyHeader().
Důležité je mít povoleno AllowCredentials(), pokud řešíte přihlašování
Na co nám nejdéle trvalo přijít je, že je potřeba povolit anonymní autentifikaci i když v aplikaci žádné anonymní požadavky nejsou potřeba (povoluje se to v IIS na obrázku níže). Je potřeba na to ovšem myslet a v aplikaci si ošetřit, že uživatel musí být přihlášen při běžném přístupu do aplikace.
Na pozadí CORS funguje tak, že vzdálený klient nejdříve udělá tzv. preflight request metodou OPTIONS a v hlavičce pošle informace, na jakou URL chce jakou metodou kdo přistupovat. Pokud není povolena anonymní autentifikace, OPTIONS požadavek selže (vrátí 401), protože v hlavičce preflight requestu se dle specifikace https://fetch.spec.whatwg.org/#cors-preflight-fetch autorizační hlavička neposílá. V takovém případě vzdálený klient není schopný zjistit, zda bude mít oprávnění udělat skutečný požadavek, a tak celá komunikace selže (nebo se chová nepředvídatelně – viz podivnosti výše).
Technické podrobnosti např. zde: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Nakonec pro přehlednost ještě schéma posílání CORS požadavků:
Při použití cookie authentizace z nuget balíčku Microsoft.AspNetCore.Authentication.Cookies 2.0.0 odpovídá server na požadavky nepřihlášených uživatelů se status code 302 (redirect na přihlášení). Pohledem do zdrojových kódů zjistíme, že je to trochu složitější – status kód je 302 nebo 401:
public Func<RedirectContext<CookieAuthenticationOptions>, Task> OnRedirectToLogin { get; set; } = context =>
{
if (IsAjaxRequest(context.Request))
{
context.Response.Headers["Location"] = context.RedirectUri;
context.Response.StatusCode = 401;
}
else
{
context.Response.Redirect(context.RedirectUri);
}
return Task.CompletedTask;
};
private static bool IsAjaxRequest(HttpRequest request)
{
return string.Equals(request.Query["X-Requested-With"], "XMLHttpRequest", StringComparison.Ordinal) ||
string.Equals(request.Headers["X-Requested-With"], "XMLHttpRequest", StringComparison.Ordinal);
}
Takže odpověd je různá pro ajax requesty a ostatní. Přičemž ajax request je rozpoznáván dle hlavičky requestu. Pro cross domain požadavky se tato hlavička nepoužívá, pokud není pomocí CORS nastaveno jinak.
Pokud bychom chtěli návratovou hodnotu vždy 401 (a nikdy 302), lze to řešit jednoduchou úpravou:
services. ... .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
{
// Vestavěná metoda OnRedirectToLogin rozlišuje Ajaxové a ostatní requesty. Pro Ajaxové se vrací 401, pro ostatní 302 (Redirect).
// Rozlišení requestů je dáno existencí hlavičky X-Requested-With, avšak ta se v cross domain requestech neposílá.
// Proto metodu nahrazujeme tak, aby vždy vracela 401.
options.Events.OnRedirectToLogin = context =>
{
context.Response.StatusCode = 401;
return Task.CompletedTask;
};
});
Záznam z interního vzdělávacího okénka HAVIT z 19.10.2017 je publikován na našem HAVIT YouTube Channel. Téma prezentoval Jiří Kanda:
Dotčená témata:
Pokud máme API, které je s authentizací pomocí JWT (JwtBearer) a chceme pomocí Swashbuckle/Swaggeru naše API testovat, je možné se pomocí Swashbuckle/Swaggeru přihlásit a získaný token (id_token/JWT) předávat do API automaticky.
Swashbuckle/Swagger má podporu pro OAuth2, nikoliv však pro OpenID Connect. Avšak implementace OAuth Googlu umožní získat id_token (JWT) pro OpenID Connect. Chce to však jeden trik v javascriptu, který vymění hodnotu response_type „token“ za „token id_token“.
public IServiceProvider ConfigureServices(IServiceCollection services)
{
...
services
.AddAuthentication(options => options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options => ... );
...
services.AddSwaggerGen(c =>
{
...
c.AddSecurityDefinition("oauth2", new OAuth2Scheme
{
Type = "oauth2",
Flow = "implicit",
AuthorizationUrl = "https://accounts.google.com/o/oauth2/v2/auth",
TokenUrl = "https://www.googleapis.com/oauth2/v4/token",
Scopes = new Dictionary<string, string>
{
{ "openid profile email", "Default scopes" }
}
});
c.OperationFilter<AuthorizeCheckOperationFilter>();
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.UseSwaggerUI(c =>
{
// Swashbuckle/Swagger podporují jen OAuth. Pro OpenID Connect je potřeba namísto "response_type=token" posílat "response_type=token id_token". To zajistíme hackem v javascriptu.
// Google OAuth navíc vyžaduje parametr nonce, který je v hacku rovněž přidán.
c.InjectOnCompleteJavaScript("/swagger-ui-customization.js");
c.ConfigureOAuth2("client-id", "client-secret", "http://localhost:PORT/swagger/ui/o2c-html", "application-name");
c.SwaggerEndpoint("/swagger/current/swagger.json", "Current");
});
Třída AuthorizeCheckOperationFilter zajišťuje doplnění informací o security pro Swashbuckle/Swagger:
internal class AuthorizeCheckOperationFilter : IOperationFilter
{
public void Apply(Operation operation, OperationFilterContext context)
{
// Alternativní implementace: https://github.com/domaindrivendev/Swashbuckle/blob/master/Swashbuckle.Dummy.Core/SwaggerExtensions/AssignOAuth2SecurityRequirements.cs
// Check for authorize attribute
var hasAuthorize = context.ApiDescription.ControllerAttributes().OfType<AuthorizeAttribute>().Any() || context.ApiDescription.ActionAttributes().OfType<AuthorizeAttribute>().Any();
if (hasAuthorize)
{
// přidá do dokumentace možnou odpověd - 401
operation.Responses.Add("401", new Response { Description = "Unauthorized" });
// přidá informaci o tom, že se má použít pro volání metody authentizační token (zobrazí se červený vykřičník)
operation.Security = new List<IDictionary<string, IEnumerable<string>>>
{
new Dictionary<string, IEnumerable<string>>
{
{ "oauth2", new string[] { "openid profile email" } }
}
};
}
}
}
Dále je potřeba do rootu webu umístit soubor swagger-ui-customization.js, který provádí ukrutný hack nad window.open:
// Swagger UI does not support custom response_type parameters. Azure Active Directory requires an 'id_token' value to
// be passed instead of 'token' (See https://github.com/swagger-api/swagger-ui/issues/1974).
window.swaggerUiAuth = window.swaggerUiAuth || {};
window.swaggerUiAuth.tokenName = 'id_token';
if (!window.isOpenReplaced) {
window.open = function (open) {
return function (url) {
url = url.replace('response_type=token', 'response_type=token%20id_token&nonce=456');
console.log(url);
return open.call(window, url);
};
}(window.open);
window.isOpenReplaced = true;
}
Záznam z interního vzdělávacího okénka HAVIT z 21.9.2017 je publikován na našem HAVIT YouTube Channel. Téma prezentoval Jiří Kanda:
Dotčená témata:
