Hvordan konfigurerer og integrerer man .NET MAUI med Blazor og minimal API?

Når man udvikler moderne applikationer med .NET MAUI og Blazor, er det essentielt at forstå integrationen mellem de forskellige lag i applikationen – fra brugergrænsefladen til backend-tjenester. I denne proces er namespace-ændringer, korrekt konfiguration af XAML-filer og overgangen fra ContentPage til Shell centrale elementer. I MainPage.xaml sættes titlen til "Home", hvilket skaber en klar og genkendelig startside for brugeren. Derefter tilføjes en ny ContentPage, AppShell.xaml, hvor den oprindelige rod erstattes med en Shell-komponent, og projektets Views namespace importeres med en præfiks for at organisere visningerne. Shell'en konfigureres med flere tabs og routes, som er case-sensitive, hvilket understreger vigtigheden af konsistens i navngivning og navigation.

Overgangen i AppShell.xaml.cs fra ContentPage til Shell-klasse ændrer applikationens navigationsarkitektur markant og muliggør en mere dynamisk og skalerbar brugeroplevelse. Samtidig ændres MainPage i App.xaml.cs til at pege på AppShell, hvilket sikrer, at navigationen benytter den nye shell-struktur. Kørsel af applikationen på forskellige platforme – Android og Windows – demonstrerer .NET MAUI’s platformuafhængige natur. Valg af emulatorer og målplatform sker via Visual Studio’s toolbar, hvor udvikleren kan teste brugergrænsefladens funktionalitet i flere miljøer.

På serversiden skabes en minimal API-webservice til kategorier og produkter i Northwind-databasen. Ved at tilføje et nyt webservice-projekt med skabelonen ASP.NET Core Web API uden controller-baserede API’er, men med minimal APIs, optimeres koden til at være mere kompakt og læsbar. Integration af databasekonteksten via projekt-referencer sikrer konsistens i dataadgangen. Justering af launchSettings.json til at definere specifikke porte for HTTP og HTTPS samt aktivering af OpenAPI support muliggør nem test og dokumentation af API’erne gennem Swagger.

I Program.cs fjernes unødvendige services som vejrtjenesten, mens HTTPS-omdirigering deaktiveres under udvikling for at undgå komplikationer. Minimal API-endpoints defineres for operationer på kategorier, hvilket demonstrerer en effektiv måde at implementere RESTful services uden det fulde overhead af controllerklasser. Dette giver udvikleren bedre kontrol over endpoints og reducerer kompleksiteten i projektet.

Det er væsentligt at forstå, at den skiftende arkitektur mod minimal API og Shell-baseret navigation ikke blot er et spørgsmål om syntaks eller filstruktur, men et paradigmeskifte i, hvordan moderne .NET-applikationer designes og skaleres. Det kræver en solid forståelse af komponenternes livscyklus, routing, og tilstandshåndtering på tværs af platforme. Desuden bør læseren være opmærksom på nødvendigheden af nøje versionsstyring af framework og emulatorer for at undgå uventede kompatibilitetsproblemer.

Hvordan forbinde og administrere Azure SQL Edge via Docker og Visual Studio

Når du arbejder med SQL Server i Azure, har du mulighed for at vælge mellem flere forskellige installationsmetoder, afhængig af dine behov og miljø. En af de mere praktiske løsninger er at bruge Azure SQL Edge i en Docker-container, især når du ikke har adgang til en Windows-maskine eller ønsker at undgå ekstraomkostninger ved at bruge Azure-ressourcer. Azure SQL Edge er en minimal version af SQL Server, som er designet til at køre på tværs af platforme, herunder Linux, Mac og Windows. Denne version inkluderer kun database-motoren og er derfor ideel til udvikling og test.

For at komme i gang med Azure SQL Edge i Docker skal du først installere Docker, hvilket kan gøres via deres officielle dokumentation. Når Docker er installeret og startet, skal du trække den nyeste containerbillede af Azure SQL Edge ved hjælp af kommandoen:

bash
Copy code
docker pull mcr.microsoft.com/azure-sql-edge:latest

Når billedet er blevet trukket, kan du køre containeren med følgende kommando:

bash
Copy code
docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=s3cret-Ninja' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge

Her er det vigtigt at vælge et stærkt kodeord, da Azure SQL Edge kræver, at adgangskoden er mindst 8 tegn lang og indeholder tegn fra tre af de følgende fire sæt: store bogstaver, små bogstaver, cifre og symboler. Uden dette krav vil containeren ikke kunne oprette forbindelse til SQL Edge-motoren.

For at oprette tabeller og indsætte data i din database skal du kopiere og indsætte SQL-scriptet fra filen Northwind4AzureSQLedge.sql i forespørgselsvinduet og køre det. Når du ser beskeden "Command completed successfully", er tabellerne, såsom Categories, Customers og Products, blevet oprettet, og du har nu en fungerende Azure SQL Edge-database, som du kan arbejde med i din konsolapplikation.

Derudover er det også nyttigt at være opmærksom på, hvordan T-SQL fungerer i SQL Server. T-SQL (Transact-SQL) er SQL Servers dialekt af Structured Query Language og bruges til at interagere med data i SQL-databasen. T-SQL er ikke case-sensitive, hvilket betyder, at du kan skrive SQL-kommandoer som SELECT, select, int eller INT, og det vil blive forstået korrekt af serveren.

Når du arbejder med T-SQL, skal du være opmærksom på de forskellige datatyper, som SQL Server understøtter. For eksempel kan du bruge datatyper som bigint, decimal, varchar, og datetime, afhængigt af hvilken type data du arbejder med. Desuden kan du oprette kommentarer i dine SQL-scripts for at gøre dem lettere at forstå og vedligeholde. Dette gøres ved at bruge -- for at kommentere ud en linje eller /* og */ for at kommentere ud et blok af kode.

En anden vigtig komponent i SQL Server er variabler. I T-SQL erklæres lokale variabler ved at bruge DECLARE og navngives med et @-tegn foran. Variabler bruges til at opbevare midlertidige data, som du senere kan referere til i dine SQL-kommandoer.

Når du arbejder med SQL Edge i Docker eller andre SQL Server-implementeringer, er det også vigtigt at forstå, hvordan du skal håndtere forbindelser og sikkerhed. Forbindelser til SQL Server bør altid være krypterede, og det anbefales at bruge sikre loginmetoder, som f.eks. certificater eller brugernavne og adgangskoder, for at beskytte dine data mod uautoriseret adgang.

Hvordan beskytte brugerdata med kryptering og signering i C#

I moderne softwareudvikling er beskyttelsen af brugerdata afgørende. En af de mest grundlæggende teknikker til at beskytte brugerens adgangsoplysninger er brugen af saltede og hashede adgangskoder. I denne artikel udforsker vi, hvordan man kan implementere brugerstyring med kryptering i C# ved hjælp af saltning og hashing. Vi ser også på, hvordan data kan signeres og valideres for at sikre, at de kommer fra en betroet kilde.

Først opretter vi en User-record i et bibliotek, der gemmer brugerens navn, en tilfældigt genereret saltværdi og den saltede og hashede adgangskode. Dette kan opnås med følgende kode:

csharp
Copy code
public record class User(string Name, string Salt, string SaltedHashedPassword);

csharp
Copy code
public static User Register(string username, string password)
{
    // Generere en tilfældig salt
    RandomNumberGenerator rng = RandomNumberGenerator.Create();
    byte[] saltBytes = new byte[16];
    rng.GetBytes(saltBytes);
    string saltText = ToBase64String(saltBytes);
    // Salt og hash adgangskoden
    string saltedHashedPassword = SaltAndHashPassword(password, saltText);
    User user = new(username, saltText, saltedHashedPassword);
    Users.Add(user.Name, user);
    return user;
}

Når en bruger senere logger ind, valideres den indtastede adgangskode mod den saltede og hashede adgangskode, der er gemt i systemet. Dette gøres i metoden CheckPassword:

csharp
Copy code
public static bool CheckPassword(string username, string password)

{
    if (!Users.ContainsKey(username))
    {
        return false;
    }
    User u = Users[username];
    return CheckPassword(password, u.Salt, u.SaltedHashedPassword);
}

I denne tilgang er det vigtigt at forstå, at selvom to brugere har den samme adgangskode, vil de have forskellige saltværdier, hvilket resulterer i forskellige hashede adgangskoder.

En af de vigtigste principper i sikkerhedsdesign er at sikre, at følsomme data aldrig overføres eller gemmes uden at blive krypteret. Dette gælder især for adgangskoder. I stedet for at gemme adgangskoderne som almindelig tekst, skal vi sørge for, at de er blevet saltet og hashet. Hashing er en envejstransformering, hvilket betyder, at den oprindelige adgangskode ikke kan genskabes fra den hashede værdi.

Signering af data kan gøres med en offentlig-nøglekryptografisk metode som RSA. Her er et eksempel på, hvordan man kan implementere signering og validering af data med RSA og SHA256 i C#:

csharp
Copy code
public static string GenerateSignature(string data)
{
    byte[] dataBytes = Encoding.Unicode.GetBytes(data);
    SHA256 sha = SHA256.Create();
    byte[] hashedData = sha.ComputeHash(dataBytes);
    RSA rsa = RSA.Create();
    PublicKey = rsa.ToXmlString(false);  // Gem kun den offentlige nøgle
    return ToBase64String(rsa.SignHash(hashedData, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1));
}
public static bool ValidateSignature(string data, string signature)
{

    if (PublicKey is null) return false;

    byte[] dataBytes = Encoding.Unicode.GetBytes(data);
    SHA256 sha = SHA256.Create();
    byte[] hashedData = sha.ComputeHash(dataBytes);
    byte[] signatureBytes = FromBase64String(signature);
    RSA rsa = RSA.Create();
    rsa.FromXmlString(PublicKey);
    return rsa.VerifyHash(hashedData, signatureBytes, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

Når man anvender RSA til at signere data, skal man kun bruge den offentlige nøgle til at validere signaturen. Den private nøgle holdes hemmelig og bruges til at generere signaturen.

Det er også vigtigt at forstå, at signeringen af data ikke kun beskytter dataene mod ændringer, men også giver en mekanisme til at bekræfte, at dataene stammer fra en betroet kilde. Når du modtager data, kan du validere signaturen med den offentlige nøgle for at sikre, at dataene ikke er blevet ændret, og at de kommer fra en person, der ejer den private nøgle.

Endtext