In einer klassischen Web-App kommt das Cookie mit jeder Anfrage, und die Prüfung findet jedes Mal statt. In einer Blazor Web App mit Inseln stimmt das nur für einen Teil der Seiten: Eine Server-Insel prüft die Anmeldung einmal, beim Aufbau der Verbindung, und eine WebAssembly-Insel läuft in einem Browser, dessen Code jeder lesen und ändern kann. Diese Lektion klärt, wer in welchem Modus angemeldet ist, wie das Wissen darüber nach WebAssembly kommt und welche Prüfung wo gilt.
Wo die Kladde steht
Die Lektion setzt K2 2.6 voraus: Cookie-Anmeldung und [Authorize] (K2 2.6.1), Entra ID mit Microsoft.Identity.Web (2.6.2), Rollen und Richtlinien (2.6.3) und die Rechte-Matrix (2.6.4). Die Kladde hat die Anmeldung als Endpunkte /anmelden und /abmelden, eine Fallback-Richtlinie und unter /intern die Seiten mit Inseln aus W8.1.1: den Kalender (Server) und die Kontaktliste (WebAssembly). In K2 2.6.3 heißen die App-Rollen Buero und Leitung; dieser Kurs schreibt sie englisch als Staff und Admin, behalten Sie Ihre Rollennamen. Die Entra-Anmeldung aus K2 2.6.2 bleibt, wie sie ist; die Beispiele hier benutzen die Entwicklungsanmeldung aus 2.6.1, weil sie sich testen lässt.