Záznam ze Vzdělávacího okénka HAVIT, kde Jirka Kanda ukazoval, jak nasazujeme aplikace z Azure DevOps Services.
Author Archives: Jiří Kanda
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; }; });
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; }
TFS (XAML) Builds – Jak vytvořit lokální workspace
TFS (XAML) Build vytvoří workspace na build serveru, do něj stáhne zdrojové kódy a ty kompiluje. Workspace vytváří aktivita CreateWorkspace, která vytvoří serverový workspace a není způsob, jak této aktivitě říct, aby vytvořila workspace lokální. Aktivita CreateWorkspace navíc vrací instanci reprezentující založený workspace.
Když tedy nelze při říct, že založený workspace má být lokální, lze použít drobný workaround – založit workspace jako serverový a dodatečně jej přepnout na lokální. To lze provést zavoláním metody Update na instanci vrácené z CreateWorkspace. V rámci TFS (XAML) Buildu to můžeme udělat reflexí, tedy aktivitou InvokeMethod s těmito parametry:
- Target Object: Workspace (resp. taková proměná, ve které máme vrácenou instanci z activity CreateWorkspace)
- Method Name: Update
- Parameters: In / Microsoft.TeamFoundation.VersionControl.Client.UpdateWorkspaceParameters / New UpdateWorkspaceParameters With { .Location = Microsoft.TeamFoundation.VersionControl.Common.WorkspaceLocation.Local }
O rozdílech mezi lokálním a serverovým workspacem si můžete přečíst tady nebo tady. Naše touha pro přechod ze serverového na lokální workspace byla vedena přiblížením prostředí buildu vývojářskému prostředí, zejména nenastavení read-only atributů na stažených souborech.
Quartz.NET a úplné vymazání plánu
Quartz.NET je plánovač spouštění úloh v rámci procesu aplikace. Úlohy se plánují tak, že se vytvoří Job (spouštěná úloha) a k němu triggery (kdy se spouští). Quartz.NET umí navíc plány perzistovat do databáze, což může být šikovné k tomu, aby se úloha plánu spustila i tehdy, pokud aplikace v okamžiku, kdy měla být úloha spuštěna, z jakéhokoliv důvodu neběžela – misfire. Obdobně umožní spustit job, který z nějakého důvodu nedoběhl (pád, vypnutí stroje) – recovering.
Tím, že je plán perzistentní, není vhodné jej vytvářet se při každém startu aplikace, protože tím by úplně přišlo o výhody perzistence. Plán vytváříme pouze při aktualizaci aplikace.
Existující plán se smaže Clear na Scheduleru – scheduler.Clear(). Problémem však je, že toto nesmaže plán recovering jobů. Nikdy. Pokud tedy takto smažeme plán a vytvoříme nový, plán recovering jobů zůstává zachován. Po nastartování plánovače jsou recovering joby okamžitě spuštěny.
Řešením může být rozšíření metody ClearData třídy SqlServerDelegate (pokud je perzistováno do SqlServeru touto třídou). Tato metoda je volána pod pokličkou v rámci volání scheduler.Clear(). Rozšíříme ji o volání metody DeleteFiredTriggers.
public class MySqlServerDelegate : SqlServerDelegate { public override void ClearData(ConnectionAndTransactionHolder conn) { base.ClearData(conn); DeleteFiredTriggers(conn); } }
Dále musí být scheduleru řečeno, že má tuto třídu používat. Při použití rozšíření Quartz.NET o intergraci s Windsor Castle pomocí NuGet balíčku Quartz.Windsor se název typu s assembly uvádí v konfiguraci pod klíč
<item key="quartz.jobStore.driverDelegateType">...</item>
Code Analyzers vs. generovaný kód
Pomocí analyzérů ve VS 2015 máme možnost kontrolovat programový kód různými pravidly ověřující štábní kulturu kódu. Netestuje se tedy, zda kód dělá to, co má, ale zejména to, jak je zapsán. Ale i to dokáže občas odhalit chyby v chování programu.
V aplikacích je však nejen kód ručně psaný programátory, ale často i kód generovaný různými nástroji (designer soubory od resources, aspx, atp.)
Takový kód často nesplňuje pravidla, které na vlastní kód klademe, a zároveň nemáme možnost způsob generování ovlivnit.
Jedno možností je použít global suppressions (viz Code Analysis na stránce https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx), druhou možností je vypnout kontrolu generovaného kódu ve vlastnostech projektu.
To však přináší zmatek v tom, co který analyzér považuje za generovaný kód. Pro určení, zda jde o generovaný kód používají různé nástroje různé techniky, například
- dle pojmenování souboru
- dle obsahu souboru – komentář s <auto-generated />
- nebo dle obsahu souboru – attributy u třídy
StyleCop Analyzers
Jako generovaný kód označují kód souboru (zdroj):
- jehož název končí na .designer.cs
- nebo obsahuje v komentáři text <auto-generated či <autogenerated
- nebo je soubor prázdný.
SonarLint for Visual Studio 2015
Jako generovaný kód označují kód (zdroj):
- souboru, jehož název obsahuje .g., .generated., .designer., .generated., _generated. nebo temporarygeneratedfile_
- nebo obsahuje v komentáři text <auto-generated či <autogenerated
- nebo je třída odekorována atributem DebuggerNonUserCode, GeneratedCode, ExcludeFromCodeCoverage či CompilerGenerated.
Code Analyzers
Neobsahují žádnou logiku pro odlišení generovaných souborů od ostatních (nebo se mi ji alespoň v čase, který jsem hledání byl ochoten věnovat, žádnou nenašel).
(zdroj)
Srovnání analyzérů
Tabulka ukazuje, které analyzéry považují jaký soubor za generovaný (ano = generovaný, ne = nerozpoznáno):
.designer.cs (název souboru) |
// <auto-generated> (obsah souboru) |
[GeneratedCode] (obsah souboru) |
|
Code Analyzers | ne | ne | ne |
StyleCop Analyzers | ano | ano | ne |
Sonar Lint | ano | ano | ano |
Na iPhone se zobrazuje počet nepřečtených emailů, přestože jsou přečteny všechny
Přestože mám na iPhone úplně prázdnou mailovou schránku, zobrazuje se na ikonce mailu odznak s počtem nepřečtených emailů.
Postup, který to řeší je jednoduchý:
- V nastavení účtu vypnout synchronizaci pošty
- Restartovat telefon
- Zapnout synchronizaci pošty
Vzdálené spouštění testů se nedaří: Failed to queue test run ‚…‘: A connection attempt failed…
Problém: Na build serveru (TFS 2015) spouštíme v rámci buildu unit testy. Testy jsou spouštěny vzdáleně na test serveru (test controller / test agent). Spuštění testů se nezdaří, dostáváme chybu „Failed to queue test run ‚…‘: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.“
Řešení: Ve Windows Firewallu stroje, který vzdáleně spouště testy, povolit komunikaci programu C:\ProgramFiles (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe.
Zdůrazňuji, že konfigurujeme volající stranu (build server), nikoliv volanou stranu (test server).
Zdá se, že nám výskyt tohoto problému souvisí s instalací Visual Studia 2015. Instalátor sice do firewallu několik pravidel přidal, nicméně ta nedostačovala.
MsDeploy s NTLM zabezpečením
Nasazuji aplikace pomocí WDP na server (Windows Server 2008). Pokud msdeploy.exe předám v argumentech authType=basic a dále username a password, které používám pro přihlášení, vše funguje. Tím mám ověřeno, že můj účet má oprávnění, existuje website, atp. Nechci však psát své heslo a rád bych využil integrovaného zabezpečení.
Proto z příkazové řádky vynechávám username i password a nastavuji authType=ntlm. Pokus o nasazení aplikace se nedaří, jsem odmítnut (unauthorized).
Po drobném bádání dohledávám, že Windows autentizace je pro službu wmsvc standardně vypnutá a musí se zapnout v registrech: Pod HKEY_LOCAL_MACHINE\Software\Microsoft\WebManagement\Server je potřeba vložit DWORD klíč WindowsAuthenticationEnabled s hodnotou 1. A restartovat službu wmsvc.
Poté je již možné se k serveru připojit s využitím NTLM.
Azure Powershell – nejsou vidět subscriptions
Dnes jsem narazil na situaci, kdy jsem v powershellu neviděl subscriptions, které jsem měl dříve k dispozici. Nepomáhalo ani Add-AzureAccount, ani odebrání (všech) accountů a jejich opětovné přidání.
Jako řešení zafungovalo smazání složky C:\Users\USERNAME\AppData\Roaming\Windows Azure Powershell, ve které jsou standardně uloženy “Subscription Data Files”.