Oh mein Gott ist das peinlich 😁
Ja, der Fehler lag bei mir... Da flog ne Exception, die die Registrierung unterbrochen hat. Die Exception wurde - aufgrund der massiven Dummheit des Entwicklers (also ich) - gefangen und als Debug-Type ins Log gefeuert (Log war natürlich auf Information gestellt). Tja, und so weiter und so weiter.
Aber das schöne bei sowas ist natürlich, dass ich viele Dinge in der Zwischenzeit über Azure gelernt habe. Ich kann z.B. sagen, dass App Services über docker-compose an sich super funktionieren 🙂
Gruß
Khalid
Danke für die Antwort
Ich kann mir beim besten Willen nicht vorstellen, wie daran die äußere Umgebung schuld sein soll oder kann.
Tja, frag mich mal 😁
Ok, dass Azure noch eine Liste weiterer Parameter dazu gibt, wusste ich jetzt so nicht. Dann bastel ich mal ein wenig weiter und lasse mir mal alles ausgeben, was da noch so reinkommt. Kann mir auch nur vorstellen, dass da irgendwas quer schießt.
Gruß
Khalid
Hallöle,
sorry zunächst, für den Betreff. Mir ist nichts besseres eingefallen. So, ich bin hier etwas am verzweifeln. Ich habe folgendes Setup
- .NET 5 Web API
- nuxt SPA
- nginx Proxy
Alle Komponenten werden als Docker Container gebaut und in eine Azure Registry gepumpt. Ziehe ich mir jetzt lokal alle Docker Container via docker-compose in eine lokale Umgebung und starte das Ganze, funktioniert es wie erwartet und alles ist gut. Ziehe ich die nahezu identische docker-compose Datei in ein Azure AppService, verhält sich das auf einmal etwas anders. Sprich, es geht nicht 🙂
Was genau ist das Problem?
Ich nutze MediatR für das CQRS Pattern und Lamar als DI Container. Lasse ich mir beim Start der WebAPI über einen HostedService ausgeben, was alles gescannt wurde von Lamar, sehe ich alle drei Assemblies meiner Solution. Nennen wie sie mal Project.Api, Project.Models und Project.Models.SubModel. Also die Assemblies sind da und geht auch nichts verloren (was aber auch ziemlich merkwürdig wäre, da der Docker Container lokal/AppService identisch ist). Lasse ich mir auch ausgeben, was Lamar alles registriert hat, sehe ich zig "IRequestHandler<DummyRequest, DummyResponse" Registrierungen. Alle meine RequestHandler halt. Das ist lokal.
Starte ich den AppService jetzt via docker-compose und lasse mir das Log ausgeben, sehe ich auch alle von Lamar gescannten Assemblies (die drei oben), ABER es fehlen nahezu alle Registrierungen. Es ist nur ein Bruchteil von dem, was eigentlich alles dabei ist. Einzig die Registrierungen für FluentValidation sind sichtbar. Alles andere verpufft also.
Tja, und da komme ich nicht weiter. Ich sehe den Unterschied nicht und weiß nicht, wo ich ansetzen soll. Wie gesagt, der Docker Container ist identisch. Es kann also ja an sich nicht an den Binärdaten liegen. Die Konfiguration zwischen lokal/AppService unterscheidet sich nur an der BaseURL für die nuxt Anwendung und dem ConnectionString zum Azure Sql Service. Alles andere ist ebenfalls identisch.
Woran kann das liegen, dass Lamar einfach nichts findet, obwohl er die gleichen Assemblies scannt?
Oder ist das noch ne Macke von den AppServices, da docker-compose noch experimentell ist?
Ich bräuchte einfach mal ein paar Ideen 🙂
Gruß
Khalid
Moin,
so, ich hab mir das jetzt alles mal versucht weiter detailliert anzuschauen. Sobald man eine eigene Implementierung des AuthenticationStateProviders in die Services legt und gleichzeitig die von MS zur Verfügung stehenden Extensions "AddApiAuthorization" oder "AddOidcAuthorization" verwendet, knallt es an jeder Ecke. Scheinbat castet er im Hintergrund immer auf die von ihm eigentlich injizierte Instanz des AuthenticationStateProviders.
Auch wenn es wahrscheinlich bekloppt ist, habe ich jetzt angefangen eine eigene Implementierung rund um die oidc-client Library zu schreiben und nicht die von MS bereitgestellten Mittel zu verwenden.
Aber da es eh meine ersten Gehversuche in Blazor sind, ist das ein ganz nettes kleines Projekt um besser die Mechaniken in Blazor zu verstehen.
Gruß
Khalid
Moin zusammen,
ich beschäftige mich seit geraumer Zeit mit Blazor und bin jetzt an dem Punkt angekommen, meine Test-Anwendung gegen einen IdentityServer4 zu authorisieren. Das funktioniert sogar auch problemlos. Allerdings stoße ich gerade auf ein Problem, zu dem ich nichts finde, oder ich einfach nur falsch verstehe.
Also, wenn der JWT Token vom ID4 zurückgeliefert wird, wird diese Information in den Session Storage geschrieben. Sprich, wenn ich den Browsertab schließe und einen neuen öffne, muss ich mich erneut einloggen. Das ist natürlich später für die User nicht tragbar. Blazor nutzt im Hintergrund die oidc-client.js Library. In einer vorherigen Test-Anwendung über vuejs konnte man in den UserSettings des oidc-clients den userStore mit angeben:
"userStore": new WebStorageStateStore( { store: localStorage }
Diese Möglichkeit scheint es innerhalb von Blazor nicht zu geben. Innerhalb der BlazorApp initialisiere ich die Services via
builder.Services.AddApiAuthorization(x => x.ProviderOptions.ConfigurationEndpoint = "oidc.json");
In der oidc.json stehen alle weiteren Metainformationen
{
"authority": "https://localhost:5000",
"client_id": "blazor",
"redirect_uri": "http://localhost:5001/authentication/login-callback",
"post_logout_redirect_uri": "http://localhost:5001/authentication/login-callback",
"response_type": "code",
"scope": "openid profile email",
"userStore": "new WebStorageStateStore({ store: localStorage})" // das geht hier so natürlich nicht
}
Hier kann der userStore nicht überschrieben werden, da es hier ja als String interpretiert wird.
Weiß irgendwer, wie ich Blazor (bzw. den oidc-client dahinter) dazu verdonnere, den localStorage zu verwenden anstatt den sessionStorage? Oder macht man das erst gar nicht? Und wenn ja, wie schaffe ich es das der User sich nicht jedesmal neu anmelden muss?
Gruß
Khalid
Moin,
eine gute Erklärung ist zu finden unter: https://stackoverflow.com/questions/9581745/sql-is-null-and-null
Grundsätzlich liefert eine Prüfung auf NULL via Equals immer false zurück. Du musst die Daten hier mittels "IS NULL" filtern.
Also
SQLCommand.CommandText = "DELETE FROM SteuerrechnerRechnungsdaten WHERE Rechnungsname IS NULL";
Gruß
Khalid
Moin,
siehe: ListViewItemCollection
Warum erstellst du erst eine List<ListViewItem> und fügst die Elemente dort ein? Warum nicht in der Schleife gleich per "lv.Items.Add(neu)". Die Methode AddRange nimmt ein Array ListViewItem entgegen. Deine markierte Zeile müsste also lauten "lv.Items.AddRange(arrayItems.ToArray())".
Gruß
Khalid
Moin,
auch wenn ich ThomasE. zustimme, dass solch Notifications eigentlich in den Service selber gehören, kann man solche Fälle lösen, wenn man z.B. eine Message Queue verwendet:
MSMQ and SQL Server Integration
Gruß
Khalid
Moin,
relational kann man sowas auch abspeichern und an sich ohne weiteres abfragen. Auch hier hängt dementsprechend ein Analysis Cube oder ähnliches Gebilde hinten dran. Auf Rohdaten, wie Abt schon geschrieben hat, würde ich es aber auch nicht los lassen.
Ich habe solch eine "Fußball-Struktur" selber noch nie relational designt, würde aber auch daruf tippen, dass die Tore relational gesehen eine eigene Tabelle ist. Denn nur so, wie du ja selber auch schon festgestellt hast, können beliebig viele weitere Statistiken angehängt werden (Spieler, Minute, aus ruhenden Ball, usw...).
Man nehme mal an, man habe eine Tabelle mit ganzen Zahlen, ein paar hängen zusammen, also folgen aufeinander, aber es gibt auch Lücken auf dem abgebildeten Zahlenstrahl. Use SQL to Find Missing Numbers and Gaps in Sequence of Numbers like Identity Column. Ist zwar der umgekehrte Fall, lässt sich ja aber dann einfach abändern für längste bekannte Sequenz.
Gruß
Khalid