Ich würde gerne einen SSE (Server-Side-Events) Client in C# für Blazor WASM nutzen (suche grad nach einer fertigen Lib, andernfalls implementiere ich selbst...) und lese mich dazu gerade ein.

Eine ähnliche Frage wurde bereits in einem anderen Thread gestellt.
Damals hatte Abt u.a. kommentiert

Client SSE (über Event Source) aus Deinem Code mit C# ist so in der Form nicht 1:1 heute möglich (weils Blazor noch nicht kann, rudimentär eben SignalR);

Ich frage mich nun: Warum ist das so? bzw. warum sollte das so sein? Meinem Verständnis nach kann man doch in Blazor WASM den HttpClient nutzen und damit sollte das doch implementierbar sein. Oder gibt's da ein Problem dass ich grad nicht sehe bezüglich des Streamings der Response?

Hintergrund: Ich bin grad dabei eine Blazor WASM Anwendung zu entwickeln die eine API mit SSE nutzt (Openhab). Ich bekomme das "problemlos" hin, in dem ich JS verwende - aber dafür benötige ich dann JS-Interop in beide Richtungen (daher die Anführungszeichen...). Ich fände es natürlich schon besser, dass dann komplett in C# zu machen - schließlich nutz ich ja (auch) deswegen Blazor 😉

Bart Simpson

Ja - natürlich.
Und als Zwischenschicht verwendest Du ein API Management Tool (gibts in Azure schon, oder Tyk.io oder API Umrella als unabhängige Lösungen).

Und je nach Umgebung trennen wir noch folgendes (wobei mein Fokus auch Industrie 4.0, Factories, Cloud und Co ist; weiß nicht inwiefern ihr da eine ähnliche Anforderung an die Umgebung habt)

Je länger ich über Dein Modell nachdenke, desto plausibler erscheint es mir - auch im Kontext unserer konkreten Anforderungen. 8)
Wobei ich allerdings noch nicht sicher bin, ob es wirklich zwei so strikte Management-Layer geben wird oder sollte. Aber das ist noch "im Fluss" (Hintergrund: Es gibt hier ein paar Aspekte, die ich in einem Forum nicht breittreten darf...)

Aber ich möchte mich auf jedenfall schon mal bei allen Antwortgebern bedanken! Allein die Tatsache mal was mit der Brille von jemand anderem zu sehen hat mir viel geholfen - und sei es z.T. auch "nur" die Tatsache, dass andere Leute auf die selben Lösungsansätze kommen.
Weitere Anregungen sind natürlich immer gern gesehen! 😁

Bart Simpson

P.S. @Abt: Ich bewege mich exakt in dem von Dir genannten Umfeld - wobei ich aber bei vielen (zumindest aktuell) nicht "Industrie 4.0" hinschreiben würde, sondern eher 0.9 beta 2 :evil:

Hi,

schon mal vielen Dank für die Antworten. Die jeweiligen Tendenzen zeigen mir jetzt schon, dass ich nicht komplett falsch liege mit meinen Ansichten 😁
Ich versuch mal auf die für mich wesentlichen Punkte einzugehen:

Das verstehe ich aber nicht so ganz. Vor allem b). Viel zentraler als Dein Kernel Layer kann es doch gar nicht mehr werden??

Was ich meinte war im Prinzip: Es gibt a) das schon erwähnte Modul zur Benutzerverwaltung und evtl. b) zusätzlich in gewisser Weise die selbe Funktionalität irgendwie nochmal im Kernel - aber eben "nur" für die Nutzung von dort aus. Und damit ergäbe sich eine gewisse funktionale Doppelung (was ich ja auch selbst kritisiert habe).
Die Idee mit dem Proxy klingt erst mal ganz net - aber dann muss man auch kucken, dass es nicht den Proxy um des Proxy's Willen gibt. Denn dann könnte u.U. auch direkt von "extern" mit der Funktionaliät im Kernel kommuniziert werden.
Ich weiss nicht so recht, ob dann nicht wieder Dein vorgeschlagener Punkt 2. der bessere wäre.

Aber vielleicht ist das mal ein Anfang für:

und freue mich auch über eifrige Diskussionen

Läuft! 😁

zB. für HealthCheck und Co nimmt man in vielen Fällen die Service Registry

Das ist auch genau unser Plan 😁 Ich hab nur das in gewisser Weise falsche oder zumindest suboptimale Beispiel HealthCheck gewählt, weil's so schön plakativ ist und damit auch jemand der sich noch nicht konkret mit der Thematik beschäftigt hat auch eine Vorstellung vom "Plan" bekommen kann... Verzeih also die bewusste Irreführung. 😉

Der Punkt, dass die zentrale Stelle keine Autorisierung machen kann/soll ist an sich ein valides Argument. Würdest Du den Standpunkt auch weiterhin vertreten, wenn ich folgende "Erweiterung" einbaue?*Das zentrale Module ist zuständig für die Authentifizierung (ähnlich wie Du das schreibst, von daher sag ich mal: -> Check!) *Die Nutzenden (externen, "drüberliegenden") Programme bekommen zusätzlich Zugriff auf eine Api, mit der sie an zentraler Stelle auch Informationen/Daten zur Autorisierung ablegen/verwalten können.

Hintergrund davon ist: Es kann/wird mehrere Programme geben, die sich eben jene (letztendlich) "administrative Konfiguration" (sprich: Wer darf was) teilen.

Was man in so einem System dann auch nicht vergessen darf, ist das Logging.

Den konkreten Punkt haben wir schon explizit auf dem Schirm. Ich bin aber sehr dankbar, wenn noch irgendwelche anderen Punkte/Anmerkungen kommen - einfach um nichts zu übersehen...

Bei uns ist es so gelöst, das die Verwaltung von Rechten (BL) und die Prüfung von Rechten (vereinfacht DAL) getrennt sind.

Das wollen wir grundsätzlich auch tun. Allerdings ist es "von außen betrachtet" dann doch wieder in einem Modul verortet - wenn auch u.U. über eine weitere/andere API zu erreichen.

U.a. weil unser Projekt in .net Core entwickelt werden soll, haben wir uns die dort vorhandenen Mechanismen / Lösungen schon genauer angekuckt und planen auch einiges von den Konzepten und Ideen bei uns einfließen zu lassen. Für unseren speziellen Anwendungsfall können wir aber aller Wahrscheinlichkeit nach nicht oder nicht vollständig darauf zurückgreifen... Da ist aber noch alles "im Fluss"...

Grundlegend Probieren wir in den Layern so „hoch“ wie möglich zu prüfen ob die Rechte/Lizenz vorhanden ist.

Das favorisiere ich im Prinzip auch. Allerdings gilt natürlich auch die Prämisse "never trust user input" und es darf natürlich nicht durch eine solche Verlagerung der Prüfung dazu kommen, dass angedachte Absicherungen/Kontrollen ausgehebelt oder umgangen werden können.
Um bei meinem Bild mit dem Betriebssystem zu bleiben: Wenn Dir die UI der Systemsteuerung nicht erlaubte eine kritische Stelle umzukonfigurieren, dann solltest Du das auch nicht können, wenn Du direkt versuchst, z.B. die Registry zu editieren.

Bart Simpson

Hallo zusammen,

ich konzipiere gerade (mit Kollegen) an einem größeren Softwareprojekt, welches Basis-Infrastrukturdienste für weitere Software zur Verfügung stellen soll (ich sprech mal bildlich: Eine Art Betriebsystem für andere Software).
D.h. es soll einzelne "Module" geben (Stichwort: Microservices), die für sich genommen funktionieren können und im Zusammenspiel miteinander Ihre Stärken ausspielen - diese sollen aber auch und vor allem genutzt werden von Software die "weiter oben" läuft.
"Unter" den Modulen soll es einen Layer geben, der sich -vereinfach gesagt- um die Verwaltung eben jener Module kümmert. So soll dort z.B. ein ggf. nötiger Dienst gestartet werden oder auch eine Art "Health Checking" für die Module laufen (Um beim Bild von oben zu bleiben: Der Kernel des Betriebssystems). Grundidee ist es dabei, den unteren Layer so schlank wie möglich und damit einfach und performant zu halten.

So weit so schön (und einfach)... :evil:
Nun soll es unter anderem ein Modul geben, welches eine zentrale Benutzer- und Rechteverwaltung erlaubt (Authentifizierung und Authorisierung). Damit sollen weitere Programme in die Lage versetzt werden, diese für sie nötige Funktionalität an eine zentrale Stelle zu delegieren. Auf den ersten Blick sofort etwas was man im Layer für die Module ansiedeln möchte, da es sich augenscheinlich ja um ein solches handelt.
Doch dann gibt es leider Anforderungen an den untersten Layer (im Bild: der Kernel), die ebenfalls irgendwie einer Rechteprüfung unterliegen müssen. (Beispielsweise: Wer darf die Konfiguration für z.B. das Startverhalten von Modulen ändern)

Nun stellt sich die Frage: Welche Softwarekomponente führt die dafür nötigen Prüfungen durch? 🤔 *Das selbe Modul wie oben? Damit bringt man aber eine (eigentlich unnötige und auch unerwünschte) Abhängigkeit des untersten Layers von einer darüber liegenden Schicht ins Spiel... *Eine (Kernel-) eigene Implementierung der Rechteprüfung? Damit wird a) u.U. Code gedoppelt und vor allem b) die Idee der zentralen Benutzerverwaltung ad absurdum geführt

Sieht jemand noch weitere Alternativen? Hat jemand gute Vor- / Ratschläge für die Lösung des Problems? Ich wäre für jedewede Information dankbar und freue mich auch über eifrige Diskussionen - denn damit bekommt man immer einen anderen Blickwinkel, der einem auch mal die Augen öffnen kann. Betriebsblindheit ist schließlich eine Berufskrankheit für Softwareentwickler... 😉

Bart Simpson

Es geht aber auch ohne Nachrichtenschleife: Mit 'nem KeyboardHook

Bart Simpson

Hi,

für das schon angesprochene ASP.net MVC gibt's recht schöne Tutorials - z.B. eines rund um das Thema Anmeldung etc. - zu finden unter http://www.asp.net/mvc/...

Bart Simpson

Das Pessimistische Locking lässt sich ohne Service nur sehr schwierig richtig implementieren.

...naja. Sooo schwer ist das nun auch nicht, zumindest wenn man "den Ball flachhält" 8)
Wir tun das hier ungefähr wie folgt: Der Zugriff auf einen Datensatz erfolgt nicht über die Tabelle selbst, sondern über eine Stored Procedure, die beim Zugriff zwei (zusätzliche) Felder in der Tabelle bearbeitet bzw. auswertet. Das eine beinhaltet ggf. den Client, der den Datensatz gerade bearbeitet (also "das LOCK besitzt"), das andere den Zeitpunkt, bis zu dem die Sperre (noch) gültig ist.
Wenn ein Client "als erster" zugreift, werden die beiden Felder aktualisiert und er bekommt in einer weiteren (berechneten) Spalte im Ergebnis mitgeteilt, dass der Datensatz schreibbar ist.
Kommt nun ein zweiter Client, so wird dies an den beiden Spalten erkannt, und der Client kriegt über die berechnete Spalte mitgeteilt, dass der Datensatz Read-Only ist.

Zu beachten sind dann noch die folgenden Punkte:
a) Wenn ein Client das Lock für einen längeren Zeitraum braucht, muss ggf. das Timeout aktualisiert werden
b) Das normale Aufheben der Sperre muss sauber implementiert werden (z.B. beim Speichern), damit die anderen Clients nicht unnötig lange auf das Timeout warten müssen.
c) Die Dauer des Timeouts sollte sinnvoll gewählt werden
d) Die Logik der Stored Procedure muss natürlich auch mit ggf. abgelaufenen Timeouts umgehen können.
e) Das ganze ist natürlich auf einer gewissen Kooperation aufgebaut - d.h. wenn ein Client irgendwie anders zugreift oder das Read-Only Flag nicht beachtet, greift das natürlich nicht.

Gibt sicher noch ein paar Haken und Ösen bei dem Vorgehen, bei uns klappt das aber recht gut - wobei ich anmerken muss, dass unsere Clients keine Benutzer im eigentlichen Sinn sind, sondern Hintergrundprozesse, die ggf. auch mal warten können 😁

Bart Simpson

command.Parameters.AddWithValue("@MyDateParameter", DateTime.Now.Day + "." + DateTime.Now.Month);  
  

...also dazu fällt mir jetzt eigentlich nur noch eines ein: AUTSCH. :evil:

Ich hab's nicht ausprobiert und es mag durchaus sein, dass Excel diese Notation akzeptiert - aber warum verwendest Du hier so ein -mit Verlaub- String-Gefrickel, wenn es mit den Datumsfunktionen doch genau das gibt, was Du brauchst um es vernünftig zu lösen?
Spätestens wenn Du mal mit Sprachübergreifenden Daten zu tun hast (z.B. deutsches vs. englisches Datumsformat) sind die Probleme bei Deiner Lösung vorprogrammiert...

Bart Simpson

Hallo,

also mal abgesehen davon, dass ich die Anforderung hier

Leider hilft das auch nichts. Da der Tag "heute" in meinem Fall falsch wäre. Ich benötige nur den Monat und den Tag, da es eine Art: Wer hat heute Geburtstag werden soll.

nicht wirklich aus Deinen bisherigen Beschreibungen herausgelesen habe, hilft Dir das sehr wohl - allerdings sollte man sich halt ein wenig mit den Grundlagen von SQL beschäftgen...

SELECT Text,Datum FROM [Tabelle1$] WHERE month(Datum)=month(@MyDateParameter) and day(Datum)=day(@MyDateParameter);

Bart Simpson

Also wenn Du in Excel wirklich als Datum formatiert hast, dann solltest Du das auch als Datum ansprechen - und zwar richtig (sprich: so wie es sich gehört...):

OleDbConnection conn = new OleDbConnection();
            conn.ConnectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=Mappe1.xlsx" + @";Extended Properties=""Excel 8.0;HDR=YES;IMEX=1;ImportMixedTypes=Text;TypeGuessRows=0""";


            string sql = "SELECT Text,Datum FROM [Tabelle1$] WHERE Datum=@MyDateParameter;";            
            OleDbCommand command = new OleDbCommand(sql, conn);
            command.Parameters.AddWithValue("@MyDateParameter", DateTime.Today);
...

Bart Simpson

Edit: Noch so als kleiner Hinweis: Der Excel-OLE-DB-Provider ist sehr zickig, was die "Typenreinheit" innerhalb der einzelnen Spalten angeht...