Vytvoření jakéhokoliv .NET projektu znamená v současné době nutnost pracovat s csproj souborem. Visual Studio navíc tvrdohlavně trvá i na sln souboru, takže i obyčejná konzolovka je doplněná o tyto dva soubory. V minulosti k nim patřil ještě packages.config, který nesl informace o připojených NuGet balíčkách.

První krok dobrým směrem udělal Microsoft s restartem platformy (na .NET Core), když výrazně zjednodušil sémantiku csproj souborů a zbavil nás právě packages.config souborů. S příchodem .NET 10 se můžeme těšit na dvě zásadní vylepšení.

Nový solution file (slnx)

První vylepšení přidané do .NET SDK 9.0.200 jsem již ukazoval v YouTube videu . Dosavadní sln soubory můžeme zmigrovat na formát slnx, který je založený na XML a výrazně zpřehledňuje jeho obsah. Jedná se nicméně o čerstvou funkcionalitu, kterou zatím plně podporuje dotnet CLI a z mé zkušenosti i aktuální verze Rideru. Pro plnou podporu ze strany různých nástrojů bych doporučil vyčkat.

Projekty bez csproj

Zásadnější novinku přinesla čerstvá verze .NET SDK 10.0.100-preview.4. Nově totiž bude moci vytvořit program bez přítomnosti csproj souboru. To v kombinaci s top-level statements znamená, že budeme schopni napsat program založený na jediném cs souboru. A to se pro různé workery a jednoduché konzolové nástroje skutečně hodí. Neznamená to ale, že přijdeme o možnosti, které nám csproj nabízí.

Když tedy vytvoříme program.cs a vložíme do něj obligátní

Console.WriteLine("Hello World!");

můžeme pokračovat kompilací ze CLI příkazem

dotnet run program.cs

Nastavení známá z csproj se pak přenesou do cs v podobě nových direktiv. Bez vysvětlování si můžeme ukázat

#:sdk Microsoft.NET.Sdk
#:nullable enable
#:package System.Text.Json@9.0.5
#:property LangVersion 14

using System.Text.Json;
Console.WriteLine("Hello World!");

Nově je navíc možné přidat shebang řádek, který otočí C# program na multiplatformní shell skript.

#!dotnet run
Console.WriteLine("Hello from a C# script!");

Ten lze následně přímo spouštět na libovolném OS založeném na unixu.

chmod +x ./program.cs
./program.cs

Důležité je, že takto jednoduché projekty bude dále možné zkonvertovat na klasické csproj. Podporu zatím zajišťuje CLI:

dotnet project convert program.cs

Závěr

Bez ohledu na to, zda se Microsoft zavděčí vývojářům z jiných platforem, odstranění csproj souborů je revoluční změna. Z mého pohledu možná jedna z nejužitečnějších funkcí za poslední roky. Je zde ale i malá část vývojářů, která tuto změnu vnímá jako další krok k "výchově" generace vývojářů, kteří ani neví, co je to třída.

Služba AutoUpdate v pravidelných intervalech otravuje uživatele tím, že hledá aktualizace. Buď se jí to z nějakého důvodu nepodaří a nebo výjimečně ano. Aktualizace v produktech uživatel nijak nepocítí, protože se jedná zpravidla jen o rutinní buildy. Vypnout se to nedá. A i když službu tvrdě ukončíte, v nejhorší možnou chvíli se stejně znovu spustí a dál otravuje.

Odkládám si tedy řešení. Stačí jít do Finderu, pomocí CMD+SHIFT+G se navigovat do složky /Library/Application Support/Microsoft a celý její obsah odeslat do pekel.

Drzost vývojářů ale nezná mezí. Když si ručně aktualizuji Word, Excel, Teams nebo něco jiného od Microsoftu, opět se mi otravný AutoUpdate bez ostychu stáhne a zaregistruje.

Code Behind

Code behind se nijak neliší od jiných formulářů, jen je potřeba zvolit u property reprezentující soubor typ IFormFile.

public partial class Profile
{
    [SupplyParameterFromForm] private ProfileForm Form { get; set; } = new ();
}

public class ProfileForm
{
    public string Description { get; set; }
    public IFormFile File { get; set; }
}

Formulář v UI

Zdroj chyb a dlouhého trápení je zakopaný v UI. Ve formuláři se totiž musí splnit následující dvě pravidla:

• formulář musí mít nastaven enctype="multipart/form-data"
• InputFile nesmí použít two-way binding, ale pouze name

Příklad tedy může vypadat následovně:

<EditForm OnSubmit="OnSubmit" Model="Form" FormName="profile" enctype="multipart/form-data">
    <DataAnnotationsValidator/>

    <div class="form-group">
        <label for="file">File</label>
        <InputFile id="file" class="form-control" name="Form.File"/>
    </div>

    <InputText type="hidden" @bind-Value="Form.Description"/>

    <br/>
    <button class="btn btn-primary">Odeslat</button>
</EditForm>

Zpracování formuláře

Pro zpracování už stačí implementovat připravenou metodu OnSubmit. Ve většině aplikací používám Azure Storage, ale pro jednoduchost zde ukazuji práci se souborem...

private async Task OnSubmit(EditContext ctx)
    {
        await using var str = new FileStream("/Users/mholec/Temporary/" + Form.File.FileName, FileMode.Create);
        await Form.File.CopyToAsync(str);
    }

Alternativní řešení

Místo práce s IFormFile by bylo možné pracovat přímo s HttpRequest. Dá se k němu dostat přes HttpContext, který lze do komponenty předat jako cascading parameter, nikoliv přes inject.

public partial class Profile
{
    [SupplyParameterFromForm] private ProfileForm Form { get; set; } = new ();
    [CascadingParameter] private HttpContext Context { get; set; }
}

Výhodné je to při práci s více soubory nebo většími soubory. Vývojář tím získává větší flexibilitu při práci se streamem dat. Více o uploadu velkých souborů najdete v dokumentaci.

Nakonec bych ještě dodal, že místo <EditForm> lze použít úplně obyčejný <form> a k mapování použít u formulářových polí pouze name. Připravíte se tím ale o two-way binding a o validace. Pokud touto cestou půjdete, nesmíte zapomenout na vygenerování antiforgery tokenu.

<form>
  <AntiforgeryToken/>
</form>

Pro úplnost dodávám, že nový antiforgery middleware musí být v pipeline uveden vždy za authn a authz middlewares. Tedy ověřte, že v Program.cs máte pořadí následovně:

app.UseAuthentication();
app.UseAuthorization();
app.UseAntiforgery();

Dokumentace říká:

Tento rok jsem se rozhodl pro přehlednost vynechat informace o předplatném, které se stejně neustále mění. Místo toho jsem tučně zvýraznil to, čeho si obzvlášť v každé kategorii vážím a bez čeho by se mi radikálně zhoršila práce.

Historie

Podívejte se i na starší reporty. Možná v nich najdete další inspiraci.

• Report z roku 2022 - další roky s macOS, nezávislý konzultant
• Report z roku 2020 - druhý rok s macOS, nezávislý konzultant
• Report z roku 2019 - první rok s macOS, nezávislý konzultant
• Report z roku 2018 - windows, software architect, konzultant
• Report z roku 2016 - windows, software architect

Hardware

• MacBook Pro 2020 13", 2.1 GHz Apple M1, 16 GB RAM a 1 TB SSD
• Logi MX Master 3 pro Mac - myš
• Magic Keyboard - klávesnice
• ORICO 11 in 1 - dock
• Elgato Cam Link 4K - příjem obrazu z kamery
• Sony Alpha 5100 - bezzrcadlovka na videa s dummy baterií
• Rode NT-USB + - mikrofon pro natáčení videa
• Rode Lavalier - klopový mikrofon na akce

Základní výbava

Do této kategorie patří software, který mám spuštěný téměř neustále od chvíle, co jsem si pořídil macOS.

• Google Chrome - naprosto spolehlivý a bezkonkurenční prohlížeč
• Microsoft Office - používám jen PowerPoint, Word a Excel
• Mimestream - e-mailový klient s výbornou podporou Google účtů
• Finder - prohlížeč obsahu disku... nepotřebuji ani Total Commander
• Acrobat Reader - prohlížeč PDF s podporou elektronického podpisu
• Google Drive - integrovaný do Finderu, sdílení souborů
• OneDrive - integrovaný do Finderu, sdílené složky ke školení
• Zoho Mail - e-maliový klient pro Zoho účty (dotnet news a textomet)
• Zprávy - SMSkování přimo na macOS bez telefonu v ruce
• Poznámky - poznámky k podnikání, recepty a checklisty
• Připomínky - základní nástroj pro správu důležitých úkolů
• Notion - knowledge base, hlavně k ADNP asociaci
• Podcasty - přehlednější aplikace na podcasty, ocením hlavně v autě

Protože používám iPhone, dává mi největší smysl zůstat u nativních aplikací Zprávy, Poznámky, Připomínky a Podcasty. Mají naprosto bezchybnou podporu offline režimu a sdílení.

Vývojářský software

Do kategorie vývojářský software zařazuji specializovaný software pro vývoj aplikací a jejich správu.

• Rider - vývojářské prostředí, náhrada za těžkopádné Visual Studio
• Terminál - nástroje od dotnetu po diagnostické nástroje
• DataGrip - správa Azure SQL databáze
• Postman - testování webových služeb a aplikací
• ApiDog - návrh REST API v Open API Specification
• VS Code - rychlé prohlížení a editace souborů
• Redis Insight - správa redis v Azure a na localhostu
• Proxyman - proxy pro sledování síťového provozu
• LINQPad 8 - rychlé prototypování v C# a spouštění benchmarků
• MS Azure Storage Explorer - správa blob storage

Nástroje na pozadí

Aplikace, které běží většinu času na pozadí operačního systému a nějakým způsobem mi usnadňují práci. Všechny tyto aplikace používám na denní bázi.

• LastPass - správce hesel, tajemství a autologin
• Go2Shell - Finder rozšíření umí otevřít terminál ze složky
• ChatGPT - integrovaný ChatGPT v systému
• DeepL - integrovaný překladač do systému přes CTRL+C (2x)
• Pure Paste - snadnější copy-paste bez formátování
• New File Menu - umí rychle založit nový soubor ve Finderu
• CleanMyMac - průběžná čistka disku od zbytečností
• Rocket - slouží pro snadnější psaní emotikon přes dvojtečku
• Dato - ukazuje v horním řádku displeje kalendář
• Meeter - ukazuje v horním řádku displeje odkazy na online schůzky
• iStat Menus - systémový monitoring v liště
• uPic - upload obrázků ze schránky do azure storage
• Parallels - virtualizace Windows, používám kvůli školením

Terminál a CLI

Zde doporučím odkázat rovnou na mé video na YouTube, kde ukazuji oblíbené nástroje v terminálu:

• Oblíbené nástroje v terminálu (YouTube)

Účelový software

Nakonec vyjmenuji další sadu software, který pouštím podle práce, které se přechodně věnuji. Jsou to většinou nástroje, které mi pomáhají vyřešit určitý specifický úkol. Záměrně je v seznamu jen to, co alespoň jednou do měsíce použiju.

• Affinity Photo 2 - tvorba grafiky a úprava fotek
• Camtasia - nahrávání a střih videa
• Fotky - nativní aplikace pro správu fotek a jejich editaci
• Audacity - úprava zvuku pro videa
• Typora - markdown editor, který používám pro psaní článků na blog
• Inoreader - RSS čtečka, přes kterou sleduji blogy i YouTube kanály
• Luminar AI - úprava fotek, rozšíření pro aplikaci Fotky
• Airtable - interaktivní tabulky, mám tu balance sheety klientů
• PDFsam Basic - úprava PDF, split a merge PDF dokumentů
• Surfshark - VPN pro brouzdání na webech mimo ČR

Webové služby

Nakonec nesmí chybět klasické webové služby a aplikace, které běží v prohlížeči. Aby seznam nebyl nekonečný, vybírám jen takové, které alespoň několikrát do měsíce použiju

Základní software

• Google Workspace - nástroje od google a e-mail na vlastní doméně
• Google Drive - uchování dokumentů v cloudu
• Sharepoint OneDrive - sdílení podkladů ke školením a přednáškám
• Datové schránky - mám tři datovky a toto je spíše povinnost

Webařina

• Microsoft Azure - běží na něm všechny mé projekty
• GitHub - veškeré zdrojáky mých aplikací i open source
• Make - integrace služeb, částečně i "backend" mého webu
• Font Awesome - ikonky na webech, používám úplně všude
• Short.cm - zkracovač URL napojený na mou doménu odkaz.me
• Azure DevOps - build a release pipelines
• Uptime Robot - monitoring dostupnosti webových stránek
• Mailgun - posílání e-mailů pro osobní účely (logy, alerty)
• Forpsi - nakupuji zde domény, nameservery nastavuji v Azure DNS
• Email Forwarder - používám při úpravách na doménách

Video

• YouTube - sledování a tvorba videa
• Vimeo - archivace záznamů z webinářů a placeného obsahu
• Vidyard - archivace některých záznamů a videa

Marketing a grafika

• SendGrid - rozesílání vývojářských novinek dotnetnews
• Envato - různé assety pro grafiku, videa a audio

Zábava, vzdělávání a osobní

• Rohlik Premium - nechodím do obchodu, nakupuji výhradně online
• Alza Plus - pořád je co kupovat, tohle zajistí dopravu zdarma
• Pluralsights - platforma pro vzdělávání
• Apple iCloud - zálohování fotek a sdílení mezi jablečnou smečkou
• Netflix - předplatné pro film a zábavu
• DenikN - jedno z mála nezávislých médií v ČR
• Wired - technologické novinky, věda a lifestyle
• PubMed - nejčtenější zdroj v souvislosti s ADNP asociací
• Tumblr - píšu v tom blog o cestování na motorce

Finance a investice

• Fakturoid - fakturace a automatizace kolem financí
• Degiro - obchodování s ETF
• Fio E-Broker - obchodování, české akcie
• XTB - obchodování, zahraniční akcie, ETF
• Binance - kryptoměny
• PayPal - platby za služby online na webu

Doufám, že v seznamu najdete plno inspirace bez ohledu na preferovanou platformu.

• Průvodce Designem REST API najdete zde

Čistější design webu

V první řadě jsem začistil celkový design webu. Aktualizoval jsem fonty, barevné označení příkladů, citací a odkazů na související články. Dvě základní oblasti REST Design a Design First jsem v meníčku propojil do jednotného celku. Věřím, že se tak bude průvodce číst lépe.

Aktualizace obsahu

Od vzniku průvodce došlo k několika aktualizacím standardů. Dobrou zprávou je, že obsah průvodce zůstává obsahově i myšlenkově konzistentní. Na některých místech jsem však doplnil výklad a přidal nové relevantní odkazy. V kapitole Message Design je nyní zdarma začleněno video zaměřené na chybové stavy v REST API. Menší aktualizací prošla také kapitola formát dat, do které jsem přidal odkazy na další specifické normy.

Design s ApiDog

Nedávno jsem napsal článek o ApiDog (referal link), jako novém standardu pro návrh REST API. Právě ukázkový design vytvořený pomocí ApiDog jsem nyní začlenil i do průvodce. Poslední kapitola zaměřená na závěrečné ukázky tak byla obohacena o kompletní dokumentaci vzorového API - nejen pomocí nástroje Stoplight, ale i s využitím ApiDog.

Průvodce designem REST API je součástí Premium

Toto není novinka, ale občas to někomu unikne pozornosti. Pokud máte nebo si zakoupíte Premium předplatné na mém webu, automaticky získáváte doživotní přístup i k Průvodci designem REST API. Stačí jít v průvodci na stránku Aktivace účtu Premium a zadat e-mail, který používáte na mém webu. Licence by se měla vytvořit automaticky.

Užijte si obsah. Zpětná vazba na e-mail je vždy vítána.

Jak funguje elektronický podpis

Každý, kdo pracuje s elektronickým podpisem by měl mít fundamentální představu o tom, jak podepisování dokumentů funguje a k čemu podepisování v praxi slouží. Přestože by bylo přesnější používat termín "digitální podpis", svezu se pro tentokrát na vlně běžně a marketingově užívaného termínu "elektronický podpis". Pro účely článku se bude jednat o totéž.

Hashování dokumentů

Podepisovaný dokument může být různého typu. Může se jednat stejně tak o obrázek jako o PDF dokument nebo hudební skladbu ve formátu MP3. Pro zjednodušení si představme, že můžeme s každým dokumentem provést sérii matematických operací a z daného dokumentu spočítat tzv. hash. Hash je text o pevně dané délce. Stačí jakákoliv změna v dokumentu a hash se matematicky přepočítá a změní. Ve vesmíru existuje určitě mnoho dokumentů, ze kterých by bylo možné získat totožný hash. To nás ale netrápí, protože nikdo moc netuší, které to jsou. Níže se můžete podívat, jak takový hash reálně vypadá:

Výše uvedený hash jsem vypočítal pro scan mé občanky ve formátu PNG. Všimnout si můžete, že vypočítaný hash byl 2x totožný, protože byl počítán nad stejným obrázkem. Poté jsem obrázek zmenšil a spočítal hash znovu. Protože došlo ke změně obrázku, změnil se i vypočtený hash. K hashování jsem použil funkci SHA-256, která je dnes široce používaná.

Šifrování dokumentů klíčem

Nyní se dostaneme k pojmu elektronický podpis. Odesílatel, který disponuje kvalifikovaným certifikátem má k dispozici dva klíče: soukromý a veřejný. Tyto klíče jsou komplementární. Soukromý klíč vlastní pouze odesílatel a nikdo jiný s ním nikdy nepřijde do styku. Právě soukromým klíčem odesílatel vypočtený hash zašifruje a vytvoří tak elektronický podpis. Když odesílatel posílá dokument příjemci, pošle s ním i elektronický podpis.

Příjemce má od odesílatele k dispozici dokument, ze kterého si může spočítat opět ten samý hash a s pomocí veřejného klíče ověřit, zda byl tento stejný hash podepsán klíčem soukromým. Kdyby někdo v mezičase dokument změnil, pak by příjemce spočítal jiný hash a tudíž by ani neseděla kontrola pomocí veřejného klíče. Znamená to, že elektronický podpis nebrání změně dokumentu. Pouze umožňuje ověřit, že se dokument od podepsání soukromým klíčem nezměnil.

Zvídavého čtenáře možná napadne, proč vlastně potřebujeme hash. Proč rovnou nepodepisujeme celý obsah původního dokumentu? Jsou to přeci také "jedničky a nuly". Bylo by to sice možné, ale velmi zdlouhavé. Šifrovat celé dokumenty asymetricky by trvalo příliš dlouhou dobu. Proto se z nich vypočítává hash o pevné délce, která se uvádí v bitech.

Svou pevnou délku má také soukromý a veřejný klíč. Když narazíte na pojem SHA-256/RSA, bavíme se o hashování o délce 256 bytů (2048 bitů) a šifrovacím algoritmu RSA (Rivest, Shamir, Adleman). Čím je velikost klíče delší, tím je obecně šifrování bezpečnější a zároveň pomalejší. V současnosti je pro běžné scénáře zcela dostačující klíč o délce 2048 bitů.

Soukromý i veřejný klíč mají podobu tzv. certifikátů. Tím se dostáváme k hlavnímu marketingovému pojmu. Když si jdeme "koupit elektronický podpis", vlastně si kupujeme certifikát. Certifikát je fyzický soubor v počítači, který vedle klíče obsahuje i další data. Například informace o držiteli a vydavateli certifikátu nebo datum vydání certifikátu. Zakoupený certifikát je sám o sobě podepsán soukromým klíčem certifikační autority.

Existují různé formáty certifikátů. Vizuálně to může vypadat takto:

V praxi bývá zvykem, že si v počítači vytvoříme tzv. CSR (certificate signing request). V rámci vytváření CSR vznikne soukromý a veřejný klíč. Veřejný klíč je přímo součástí CSR, zatímco soukromý klíč je uchován bezpečně v počítači. Součástí CSR je také identifikace žadatele. Vzniklý CSR musí následně podepsat soukromým klíčem certifikační autorita.

Certifikační autorita

Pokud je jasný princip elektronického podpisu, je na čase vyjasnit si dále pojem "certifikační autorita". Vytvořit certifikát si totiž může v počítači úplně každý a zcela zdarma. Následně lze takovým certifikátem podepsat dokument a ten někomu poslat k ověření. Adresát pak může a nemusí podpisu věřit. V tom je ten háček. Technicky si mohu vytvořit certifikát a zapsat do něj libovolné údaje. Mohu se vydávat za kohokoliv chci. To nás přivádí k pojmu "důvěryhodnost certifikátu". Když si certifikát vytvořím sám, není příliš důvěryhodný. Dokument podepsaný nedůvěryhodným certifikátem by žádný úřad neměl uznat. Záměrně píšu neměl, protože kvalifikovanost úředníků je prachbídná a v praxi... raději nic. Zkrátka pro komunikaci potřebujeme důvěryhodný certifikát.

Důvěryhodný certifikát nám musí vydat nezávislá a důvěryhodná instituce. Instituce, která je důvěryhodná pro odesílatele i příjemce. Obvykle je řeč o akreditované certifikační autoritě. Když chci tedy certifikát, požádám o něj certifikační autoritu. Úkolem certifikační autority je ověřit mou totožnost a mimo jiné za tuto službu si autorita vezme určitý poplatek. Veškeré dokumenty tedy podepisuji certifikátem, který byl vydán certifikační autoritou. Důvěryhodným certifikátem. Příjemce pak kromě ověření dokumentu sleduje i důvěryhodnost certifikátu.

Celé je to velmi podobné principu ověření podpisu notářem, přestože to však úroveň notářsky ověřeného podpisu pochopitelně nemá. Když chceme někomu předat plnou moc, na úřadě by dotyčný s běžným podpisem nepochodil. Většinou musíme nechat podpis úředně ověřit někým, komu úřady důvěřují. Stačí zajít na poštu, která je takovém případě důvěryhodnou autoritou. Nyní je již podpis důvěryhodný.

Typy elektronických podpisů

Aby bylo vše ještě složitější, existuje hned několik typů elektronických podpisů (certifikátů) a každá certifikační autorita vydává jen určité typy. Zákon č. 297/2016 Sb. je v tomto ohledu konkrétní a ukládá například orgánům veřejné moci akceptovat pouze zaručený elektronický podpis založený na kvalifikovaném certifikátu.

Pokud chce podnikatel komunikovat pouze s jinými firmami, obvykle si vystačí s levnějšími komerčními/osobními certifikáty, které vystavuje mnoho certifikačních autorit. Platí, že "vyšší verze" jsou dražší, vyžadují přísnější stupeň ověření a jejich vystavení tudíž trvá delší dobu. Níže se můžete podívat na tabulku pro porovnání:

V tabulce jsou vidět certifikační autority Sectigo a DigiCert. Zvýrazněný DigiCert Premium CLASS 2 používám pro komunikaci s firmami já. Firma má jistotu, že certifikátem podepsané dokumenty jsou podepsané mou osobou a organizací.

Žádný z výše uvedených certifikátů není kvalifikovaný. Orgány veřejné moci v ČR dokumenty podepsané takovým certifikátem nesmí uznat. Soudy, sociální správa, celnice, zdravotní pojišťovny nebo různé státní instituce vyžadují nejčastěji podepsání kvalifikovaným certifikátem a ten vydává jen omezené množství autorit. V ČR se jedná o PostSignum, eIdentity a I.CA. Ve všech případech si certifikační autorita provádí důkladné ověření (například občanským průkazem).

Jaký typ certifikátu si vybrat a jakou zvolit autoritu?

Záleží na potřebách každého podnikatele. Proces vystavení certifikátu je poměrně složitý a řádově složitější v případě kvalifikovaných certifikátů. Za sebe musím říct, že pro komunikaci s českými orgány veřejné moci plně dostačuje datová schránka. Téměř jakýkoliv dokument poslaný datovkou je uznán. Nenašel jsem za poslední roky žádnou situaci, kdy bych si nevystačil s datovkou a potřeboval bych kvalifikovaný certifikát. Datovku jsem si před lety jednou vytvořil a od té doby s ní nejsou spojené žádné starosti ani náklady. Poslední dobou se navíc rozšiřuje ověřování s pomocí bankovní identity.

Doplnění 16.1.2023 Dle komentáře od Kamila Z., který jsem dostal e-mailem, existují situace, kdy je podpis založený na kvalifikovaném certifikátu nezbytný. Pokládám za užitečné příspěvek připojit:

Z mého pohledu dávají smysl spíše komerční certifikáty. Používám je k podepisování různých dokumentů (NDA, nabídky, smlouvy) vůči firmám. Ze všech certifikačních autorit mám mnoho let dobrou zkušenost s DigiCert. Jejich certifikáty používám i pro zabezpečení všech mých webů.

Potřebujete-li certifikát výhradně ke komunikaci s jedním subjektem (jeden účel), není od věci zjistit, jaké má tento subjekt požadavky na důvěryhodnost certifikátu. Byla by škoda zaplatit za certifikát, jímž podepsaný dokument příjemce neuzná. Jestliže chcete obecný a široce uznávaný komerční certifikát, vybírejte ten, který obsahuje verifikaci e-mailu, jména a firmy.

Postup k získání komerčního certifikátu

Certifikát lze zakoupit u mnoha českých firem. Háček je v tom, že uznávané certifikační autority jsou zahraniční, a tudíž se ve všech případech jedná o přeprodej. Český e-shop má jen roli mediátora mezi kupujícím a certifikační autoritou. Slouží k vytvoření objednávky a inkasování plateb, ze kterých si část odepíše na svůj účet a zbytek pošle certifikační autoritě. Kupující má na druhou stranu českou podporu, která s procesem získání certifikátu pomáhá. Postup vypadá zhruba následovně.

1. Objednávka

V první řadě je nutné si vybrat vhodný e-shop a certifikát. Já osobně mám dobrou zkušenost s obchodem SSLmentor. Stačí vybrat vhodný certifikát, dobu platnosti a vyplnit osobní údaje. Delší platnost certifikátu znamená, že celý proces vystavení nemusíme podstupovat tak často a cena je většinou i výhodnější. Na druhou stranu u certifikátu delší dobu platnosti riskujeme, že bude kompromitován.

2. Verifikace

Na základě objednávky provede certifikační autorita ověření identity. Zde záleží na typu certifikátu. U těch nejlevnějších s ověřením e-mailu stačí kliknout na odkaz v e-mailové schránce. V případě ověření osob je většinou nutné poslat například scan řidičského průkazu a nějaký výpis z účtu nebo jiný dokument, kde je adresa se jménem. Běžně se setkávám s ověřením telefonickým hovorem ze zahraničí, kdy se operátor zeptá na jméno, e-mail a adresu. U kvalifikovaných certifikátů může být nutná fyzická přítomnost na úřadě nebo stažení dalšího software, s jehož pomocí ověření proběhne. Velmi často se již tento krok označuje jako žádost o vydání certifikátu a může být rozdělen do více kroků.

3. Žádost o certifikát

Pokud to neudělá český e-shop sám, bude nutné vygenerovat žádost o vystavení certifikátu. Tento krok se liší od situace. Zpravidla se na základě výzvy dostanete na webovou stránku vydavatele certifikátu a tam bude nutné vyplnit veškeré informace o organizaci společně s kontaktními údaji a požadavky na certifikát. Výjimečně je v tomto kroku nutné vytvořit si svépomocí CSR. V takovém případě ale dostanete pokyny, jak to udělat. V případě certifikátu od DigiCert je tento krok volitelný. Použití vlastního CSR je vždy bezpečnější.

4. Získání certifikátu

Poslední krok se liší s ohledem na krok 3. Jednodušší varianta spočívá pouze ve stažení hotového balíčku s certifikátem v různých formátech. Jestliže bylo v kroku 3 nutné vytvořit CSR, pak certifikační autorita v kroku 4 umožní stažení certifikátu, který se musí spárovat s původním soukromým klíčem. V tomto případě jistě dodá e-shop podrobnější pokyny. Postup se totiž liší dle platformy a vydavatele certifikátu.

Postup získání kvalifikovaného certifikátu

Pro vydání kvalifikovaného certifikátu jsou k dispozici 3 autority. Jestliže vám nevadí osobní návštěva na pobočce preferované autority, pak si zvolíte PostSignum pro větší množství poboček.

Nicméně jednoznačně nejrychlejší cestou (avšak nikoli nejlevnější) k získání kvalifikovaného certifikátu je objednání komplexní služby prostřednictvím www.elektronickypodpis.cz. Elektronický podpis s.r.o. je tzv. externí registrační autoritou PostSignum, má tedy možnost prostřednictvím svých konzultantů po ČR ověřovat totožnost osob, zavádět smlouvy a vydávat jak komerční, tak kvalifikované certifikáty. Mj. též dodávají veškerý hardware – USB tokeny, čipové karty pro kvalifikovaný elektronický podpis apod. Jak mi při osobním setkání zmínil Ing. Lukáš Vaněček, majitel společnosti: „Výhodou je, že klient nemusí nikam vážit cestu, vše zajistíme v jeho sídle a nezdržíme se více jak 45 min.“ Sám jsem tuto službu vyzkoušel a byl jsem s celým procesem velmi spokojený. Odpadá tak veškeré papírování na začátku, návštěvy poboček, konfigurace certifikátu na PC, plus vás v rámci použití elektronického podpisu základně proškolí.

Porovnání k 15.1.2025

👉 eIdentity - Nenašel jsem možnost vydání certifikátu online a mají jen 3 pobočky. Za mě nepoužitelné.

👉 PostSignum - Umožňuje vydání osobního certifikátu online s tím, že ověřit identitu je nutné pomocí služby eObčanka (= musíte mít občanku s čipem a čtečku OP). Pokud tuto výbavu nemáte, musíte se stavit osobně na pobočce České pošty se službou Czech POINT. Návštěva na pobočce je nutná i pokud chcete vydat certifikát s uvedením IČ (OSVČ, právnická osoba). Výhodu vidím v tom, že poboček Czech POINT je mnoho a certifikát lze vystavit s platností 3 roky. Případně jak bylo zmíněno výše, můžete využít www.elektronickypodpis.cz.

👉 I.CA - Umožňují vydání osobního certifikátu online s tím, že pro ověření identity je nutné nainstalovat si mobilní aplikaci Zealid. V mobilní aplikaci je nutné ověřit svou identitu naskenováním občanského průkazu a obličeje. Proces je poměrně jednoduchý a projít jím můžete s pomocí návodu online. V případě certifikátů s uvedením IČ (OSVČ, právnické osoby) se i zde nevyhnete návštěvě pobočky (i když na webu je uvedeno, že se můžete obrátit na sales, takže možná to nějak jde). Pro vydání certifikátu je nutné udělat prvotní registraci. Poté musíte čekat až 24 hodin na e-mail s možností dokončení žádosti. Jestliže tedy na vydání hodně spěcháte, asi je lepší PostSignum. Na druhou stranu I.CA Vám dokáže vydat tzv. TWINS, což je kombinace kvalifikovaného certifikátu a komerčního certifikátu v jednom.

V případě vydání certifikátu pro OSVČ nebo právnickou osobu si instituce obvykle dokáže ověřit oprávněnost osoby na základě občanského průkazu a veřejného rejstříku. Dobrou osobní zkušenost mám s PostSignum, kdy jsem na poště předložil jen OP a ověření z živnostenského rejstříku si provedli sami.

Instalace kořenového certifikátu

Ještě než se pustíme do instalace vydaného certifikátu, je nutné mít v počítači nainstalovaný kořenový certifikát certifikační autority, která vám vydala váš certifikát. Kořenový certifikát totiž slouží k ověření všech certifikátů, které daná CA vydala. Máte-li počítač delší dobu, řadu kořenových certifikátů už v něm máte. Každá certifikační autorita má nicméně své kořenové certifikáty, které je nutné do počítače instalovat. Většinou mají příponu cer a na daný soubor stačí jen poklepat. Některé CA nabízí ke stažení program, který certifikáty nainstaluje a správně nastaví. Certifikát se totiž musí instalovat do složky s kořenovými certifikáty, takže vás počítač možná vyzve k zadání hesla správce.

• kořenové certifikáty I.CA
• kořenové certifikáty PostSignum
• kořenové certifikáty DigiCert

Počítač dost možná kořenový adresář označí za nedůvěryhodný. V takovém případě by byly nedůvěryhodné i certifikáty vydané danou CA. Budete muset ručně upravit nastavení kořenového certifikátu a označit ho jako důvěryhodný. Tento krok musíte udělat výhradně s certifikátem, který skutečně pochází od dané CA. Za žádných okolností neoznačujte jako důvěryhodné certifikáty soubory, jejichž původ neznáte!

Mějte na paměti, že když někomu pošlete podepsaný dokument, musí mít cílová osoba nainstalovaný kořenový certifikát od dané CA, aby mohla platnost podpisu ověřit. I z toho důvodu je dobré volit CA, které jsou široce užívané v daném prostředí.

Instalace certifikátu

Nyní máme fyzicky uložený certifikát. Nejčastěji se používá formát pfx nebo p12 dle platformy (Windows / Linux / macOS). Dle potřeby lze souborovou příponu p12 a pfx změnit. Certifikát by měl být uložen na bezpečném místě, protože s jeho pomocí může kdokoliv podepisovat dokumenty. Při exportu certifikátu doporučuji vždy nastavit silné heslo.

Aby s certifikátem bylo možné pracovat, je nutné ho uložit do úložiště certifikátů. V případě macOS stačí na certifikát pouze poklepat myší a je hotovo. Certifikát by se měl uložit na správné místo. V případě Windows je to více klikání.

Jak podepsat dokument

Stačí spočítat hash dokumentu, poté ho asymetricky zašifrovat soukromým klíčem a vzniklý podpis odeslat spolu s dokumentem. To ale nikdo ručně dělat nechce. V praxi proto použijeme software, kterému jen řekneme, že chceme dokument podepsat digitálním certifikátem. Asi nejjednodušší je použít Adobe Acrobat Reader.

Adobe Acrobat Reader si umí sáhnout do úložiště certifikátů a dokument podepsat. Pracuje s formátem PDF, takže jiné typy dokumentů budete muset do PDF převést. Používáte-li macOS, vytvoření PDF je hračka. Stačí ve finderu kliknout pravým tlačítkem nad souborem a v rychlých akcích zvolit možnost "Vytvořit PDF".

V případě běžných office dokumentů (docx, xlsx) je nejjednodušší daný dokument otevřít ve výchozí aplikaci a uložit do formátu PDF.

PDF soubor poté otevřeme v aplikaci Adobe Acrobat Reader a ze záložky nástroje vybereme položku Certifikáty. Následně zvolíme možnost Digitálně podepsat a na vhodném místě v dokumentu vytvoříme rámeček, kam se natisknou metadata podpisu. Poté aplikace nabídne certifikát k podpisu a máme hotovo.

V místě podpisu pak vznikne něco v tomto smyslu:

Tím je dokonáno.

Vlastní podoba podpisu v dokumentu

Podobu podpisu je možné v Adobe Acrobat Reader DC upravit. Po vybrání "digitálního ID" stačí kliknout na možnost upravit a poté si lze podpis přizpůsobit. V mém případě níže vidíte úpravu s použitím parafy.

Závěr

Popsali jsme si fungování elektronického podpisu. Je důležité si uvědomit, že elektronický podpis představuje záruku, že podepsaný dokument se od svého podepsání určitou identitou nezměnil. Příjemce dokumentu se musí rozhodnout, zda bude podpisu důvěřovat. Důvěryhodný digitální podpis je vytvořen s pomocí digitálního certifikátu, který vydala důvěryhodná certifikační autorita. Při komunikaci se státem je nutné podepisovat dokumenty kvalifikovaným certifikátem, který v Česku vydávají pouze 3 subjekty. Pro komunikaci se státem může být jednodušší použít datovou schránku nebo bankovní identitu. Pro komunikaci s firmami je dostačující "komerční" certifikát. Proces vystavení digitálního certifikátu je poměrně zdlouhavý, nicméně existují partneři certifikačních autorit, kteří za vámi dojedou a certifikát vám bez vaší práce na místě vystaví. Vydaný certifikát je vhodné uložit na bezpečné místo, aby nedošlo k jeho zneužití. S vydaným certifikátem lze podepisovat PDF dokumenty s pomocí aplikace Adobe Acrobat Reader.

• Aplikace Apidog je zde (referal link)

Proč přecházím na Apidog

Apidog o sobě prohlašuje, že s ním nahradíte všechno od Postmanu, přes Stoplight až po Swagger UI a Mock. To je silné tvrzení, které se kupodivu ukázalo jako pravdivé.

Vezmu to velmi pragmaticky a jen vypíšu, co aplikace umí a co mě přesvědčilo na ji přejít ze Stoplight a zařadit ji do osnovy mého školení REST API Design.

Na úvod bych zmínil, že aplikace nabízí řadu funkcí zcela zdarma a už tato základní sada funkcí je mocnější než v případě Stoplight. Zdarma lze vytvořit 5 projektů, zveřejnit dokumentaci na subdoméně a připojit až 4 kolegy. Omezením může být jen jedna verze API na jeden projekt a pak omezení na 100 tisíc requestů na mock server (což je vlastně více než dost. Vyšší plány stojí 9/18/27 USD za uživatele na měsíc, což je pořád skvělá cena.

V druhé řadě má intuitivnější rozhraní a používá terminologii, která více odpovídá OAS. Nakonec samotné rozhraní je úžasné v tom, že například rozhraní pro odesílání požadavků vypadá jako Postman. Rozhraní pro návrh endpointů vypadá jako Stoplight. A princip organizací, týmů a projektů je zase něco, co známe třeba z Azure DevOps. Pro .NET vývojáře je UI zkrátka velmi intuitivní.

Přehled postřehů

Postřehy napíšu stručně, protože už připravuji video na YouTube, kde se rozpovídám více do detailů.

1. aplikaci lze poižívat online i v podobě desktop aplikace pro windows nebo macos
2. aplikace oproti stoplight za celé hodiny používání nevykázala jedinou chybu
3. základní funkce jsou: návrh endpointů, spouštění (ála Postman) a mockování
4. oproti Stoplight lze navrhnout endpoint na základě requestu
5. chybové stavy 4xx, 5xx se automaticky mohou připojovat k endpointům
6. lze si nastavit výchozí podobu 200 stavů
7. nejen, že lze přiřazovat k endpointům tagy (pro OAS), ale endpointy lze organizovat do složek (pro dokumentaci)
8. u každého endpointu (nebo složky) si lze nastavit viditelnost (Shared, Internal)
9. je možné připojit schéma k endpointu (třeba ProductResponse) a ten dekomponovat a upravit
10. všude jsou generátory kódu do všech možných jazyků
11. když přijde řeč na .NET a serializaci, oproti swaggeru je tu i podpora System.Text.Json
12. jednotlivé endpointy lze definovat s různými vlastními stavy: designing, release, deprecated
13. kromě proměnných jsou tu chytré placeholdery ve stylu Bogusu nebo FakeIt
14. místo testů (jako v Postmanu) se používají logičtější Pre Processors a Post Processors
15. místo kolekcí se vytváří nezávislé vícekrokové testovací scénáře
16. v rámci testovacích scénář je v beta programu i funkce performance (stress test)
17. mnohem lepší možnost při generování examples (náhodně, z jiných examples, dynamické)
18. je tu podpora lokálního i cloudového mockování, které si lze zvolit při testování rozhraní
19. u mockování si lze definovat mnohem snadněji scénáře a filtry (tzv. mock expectations)
20. krásná dokumentace an pure doméně, třeba zkuste courses.apidog.io
21. v dokumentaci si lze definovat vlastní meníčko a vlastní stránky v markdown
22. všechno frčí ve světlém i tmavém schématu dle vlastních preferencí
23. přímo z dokumentace si lze vygenerovat čisté DTOčka v C# s podporou System.Text.Json
24. lze si definovat export do více specifikačních formátů (verze OAS, YAML vs JSON)
25. v dokumentaci lze nastavit vlastní favicon, logo i barvičky
26. dají se připojit i Google Analytics, nastavit CORS nebo přidat pravidla pro redirecty mrtvých stránek
27. oproti Postmanu se rozlišuje kolekce a testovací scénář, což mi vždy extrémně vadilo

Pár screenshotů

Skvělá záložka pro nastavení viditelnosti endpointů:

Hlavní strana dokumentace s libovolným textem v markdown:

Snadné generování C# třídy na základě definice kontraktu v API:

Definice testovacího scénáře:

Níže můžete vidět výsledky performance testu daného testovacího scénáře vůči funkčnímu API v Azure.

Závěr

Revoluční. Po velmi dlouhé době jsem objevil nástroj, který mohu bez výhrad doporučit každému, do navrhuje REST API. Doposud jsem doporučoval kombinovat Stoplight, Postman, GitHub a vlastní generátor dokumentace jako například ReDoc. Nově stačí pouze tento nástroj. Umí absolutně všechno, co tým potřebuje pro návrh, testování, mockování API a to včetně přehledné dokumentace s funkčními generátory.

Níže je tabulka projektů a jejich původní verze:

U naprosté většiny projektů proběhlo všechno hladce. Dva záseky jsem měl na restapi.cz a restdemo.miroslavholec.cz. Zároveň teď bude otázka, jaké chyby se eventuelně projeví v produkci.

PasswordHasher, SuccessRehashNeeded

Na webu restapi.cz mi přestalo fungovat přihlášení. V podmínce jsem vyžadoval výsledek ověření hesla striktně na success, ale protože jsem migroval z .NET 6 / EF 6, zřejmě se změnilo hashování uvnitř PasswordHasher a vracel se mi výsledek SuccessRehashNeeded. Tedy přihlášení v takovém případě je OK a pouze přehashuji heslo.

Problém s [Consumes("application/json")]

Na REST API napsaném v MVC jsem si udělal pro všechny controllery ApiControllerBase. Doteď všechno fungovalo v pořádku, ale po migraci z .NET 8 na .NET 9 (+ přechod na WebApplicationBuilder) přestal endpoint reagovat. Po cca hodině hledání jsem zjistil příčinu:

Atribut Consumes používám na tomto webu kvůli generování dokumentace. Bohužel muselo dojít ve frameworku k změně, protože všechny endpointy v takto anotovaném controlleru nově vyžadují poslat media type, jinak endpoint vrací 404 Not Found. Neviděl jsem to ani v breaking changes, takže to odhaduji na bug. Dále jsem po tom nepátral.

Zapojení Scalar pro REST API

Microsoft už do .NET 9 neaktualizuje Swashbuckle Swagger a místo toho doporučil na .NET Conf přejít na Scalar. Zapojení je celkem jednoduché. Ponechal jsem původní nastavení generování OAS pomocí Swagger toolingu, takže došlo opravdu jen k výměně UI:

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger(options =>
    {
        options.RouteTemplate = "/openapi/{documentName}.json";
    });
    app.MapScalarApiReference();
}

Výsledek si můžete prohlédnout u mé demo aplikace.

Migrace EF Core

Protože používám na všech projektech EF Core a režim migrací, vždy jsem si aktualizoval EF Core na novou verzi a vygeneroval testovací migraci. Cílem bylo ověřit, zda nedojde k nějaké chybné interpretaci kódu. Nemám rád nullable reference types, takže jsem se ani nesnažil o změny v modelu. V csproj jsem tedy vždy nastavil:

<PropertyGroup>
  <TargetFramework>net9.0</TargetFramework>
  <Nullable>disable</Nullable>
</PropertyGroup>

U mého webu následně aplikace selhala na nové breaking change v .NET 9. Při startu aplikace dojde k vyhození výjimky, pokud jsou na modelu nalezeny změny oproti poslední migraci. To by bylo fajn, kdyby v tom nebylo hned asi 5 výjimek, které v enginu vyvolají chybnou představu o tom, že se model změnil. Takže bez změny kódu jsem to vyřešil vypnutím této funkce pomocí RelationalEventId.PendingModelChangesWarning:

builder.Services.AddDbContextFactory<UnitOfWork>(options =>
{
    options.ConfigureWarnings(x =>
    {
        x.Ignore(RelationalEventId.PendingModelChangesWarning);
    });
});

Při migraci na EF Core 7 jsem ještě narazil na tradiční chybu s connection stringem. Od EF Core 7 je totiž u SQL clienta výchozí hodnota Encrypt=False změněna na Encrypt=True, což je na localhostu otravné. Stačí tedy aktualizovat connection string o toto nastavení a vše opět funguje jak má.

Static assets

U většina webových stránek jsem přešel na nové statické assety v .NET 9. U většiny aplikací stačí nahradit app.UseStaticFiles() za app.MapStaticAssets. U Blazor aplikací jsem pak upravil i cesty ke statickým souborům:

<link rel="stylesheet" href="@Assets["css/site.css"]" />
<link rel="stylesheet" href="@Assets["Holec.Web.styles.css"]" />

U některých aplikací jsem ponechal variantu app.UseStaticFiles(), protože tam používám specifické funkce přístupu do složek, které nový middleware nepodporuje. Dle dokumentace to ničemu nevadí.

U mého webu došlo k chybě, která se projevila jen v produkci. Přestože se všechny soubory správně zkomprimovaly a přenesly, prohlížeč je nedokázal interpretovat. Podezření padlo na brotli kompresi. Po delším troubleshootingu jsem zjistil, že chybu způsobuje jeden můj middleware, kde nastavuji encoding (viz. jiný workaround kvůli stream renderingu z 5/2024). Vyřešil jsem to tedy podmínkou v middleware a pro statické assety tuto hlavičku nevracím.

Závěr, sběr dat, performance

Protože jsem aktualizoval všechny aplikace na Azure Service Planu, budu sledovat nejen funkčnost aplikací, ale i výkonnost celého řešení. Brzy se můžete těšit na další článek zaměřený na výsledky měření výkonnosti v produkčním režimu. Když se neobjeví žádné chyby, budu ještě migrovat textomet.cz, kde už je zajímavější traffic. U menších aplikací se jako vždy není čeho bát a migrace je docela hladká.

Při přípravě nového školení .NET 9 si tradičně vytvářím vlastní snímky, nicméně občas potřebuji podívat se do prezentací z poslední konference .NET Conf nebo porovnat změny v posledních verzích.

Hlavní rozcestník

Zde je .NET Conf GitHub s odkazem na konkrétní repositories. Níže pak poslední roky

Pro dnešek mám velmi rychlý tip. Nedávno byl zveřejněn LINQPad pro macOS a tím pádem jsem se po letech vrátil k vytváření snippetů s pomocí tohoto programu. Naprosto excelentní je to pro účely mých školení. Snippety se ale uchovávají jako soubory s příponou linq.

Jak zajistit, aby se mi linq soubory ve VS Code obarvily jako C#? Asi nejlepší řešení je spustit si vyhledávání v nastavení (CTRL + SHIFT + P) a zadat Preferences: Open User Settings (JSON). Tím se otevře soubor settings.json, kde už stačí asociovat příponu souboru s vybraným jazykem.

{
  "files.associations": {
    "*.linq": "csharp"
  }
}

A je hotovo.