Category Archives: ASP.NET Core

ASP.NET Core včera, dnes a zítra [Miroslav Holec, HAVIT Vzdělávací okénko 3.5.2018]

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:

CORS a WebAPI

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ě:

  • Některé GET requesty fungovaly i v testovacím prostředí, ale POST, PUT a DELETE requesty nikdy.
  • GET requesty browser někdy zdvojoval (zejména v Safari na Macu), první vždy prošel (status code 200) a druhý neprošel (status code 403)
  • V Developer tools v Chrome, ani v Safari nejsou vidět autorizační hlavičky i přesto, že uživatel je přihlášený (při odchycení requestu Fiddlerem tam skutečně jsou). Ovšem na localhostu jsou vidět autorizační hlavičky vždy.

CORS v aplikaci máme nastaven celkem standardně a nepříliš restriktivně:

2018-04-10-CORS-settings

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.

2018-04-10-CORS-IIS

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ů:2018-04-10-CORS-schema

ASP.NET Core Security – CookieAuthentication vs. status code 401

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

 

Hackování webů běžnými „smrtelníky“ – záznam [Jiří Kanda, HAVIT Vzdělávací okénko 19.10.2017]

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:

  • Open Redirects
  • XSS – Cross Site Scripting, ASP.NET Request Validation
  • MIME-type injection
  • External JS references, CDN, Tag Managers
  • Cross Site Request Forgery (XSRF/CSRF)
  • CORS – Cross Origin Resource Sharing, Preflight requests
  • X-Frame-Options
  • X-Content-Type-Options
  • X-XSS-Protection

Napojení Swashbuckle/Swagger v ASP.NET Core aplikaci na Google OpenID Connect

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

ASP.NET Core Intro – záznam [Jiří Kanda, HAVIT Vzdělávací okénko 21.9.2017]

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:

  • Web vs WebAPI vs. Frontend
  • SSR – Server-side Rendering
  • ASP.NET Core vs. .NET Standard
  • Struktura projektu
  • Startup.cs
  • Program.cs

ASP.NET Core: Duplicate ‚Content‘ items were included. The .NET SDK includes ‚Content‘ items from your project directory by default.

Pokud dostanete na ASP.NET Core projektu ve Visual Studiu hlášku o duplicitním Contentu:

Error Duplicate ‚Content‘ items were included. The .NET SDK includes ‚Content‘ items from your project directory by default. You can either remove these items from your project file, or set the ‚EnableDefaultContentItems‘ property to ‚false‘ if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: ‚wwwroot\Index.html‘ Web C:\Program Files\dotnet\sdk\1.1.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets 188

…jedná se o nadrbaný .csproj a pomůže odebrat a přidat složky wwwroot z projektu:

  1. Solution Explorer – pravým na ~/wwwroot – Exclude From Project
  2. zapnout si viditelnost excludovaných souborů – Solution Explorer – Show All Files (jedna z ikonek nahoře)
  3. Solution Explorer – pravým na ~/wwwroot – Include in Project