Laden...

Teil einer Razorpage von Backend aktualisieren?

Erstellt von DerBeginner vor einem Jahr Letzter Beitrag vor einem Jahr 960 Views
D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr
Teil einer Razorpage von Backend aktualisieren?

Hello Community,

jetzt bin ich aber froh, dass ich dieses Forum gefunden habe.
Ich bin so der kleine Wald-und-Wiesenprogrammierer und stecke grade irgendwie fest.

Also folgendes.
Ich habe eine Razorpage in dessen Backend ein OPC Client auf eine Veränderung in einer Node horcht.
Im Falle, es ändert sich was, wird eine Callbackfunktion aufgerufen, die die Node und den alten und neuen Wert enthält.

Diesen Wert möchte ich nun in Echtzeit auf dem Frontend anzeigen.
Und hier komme ich nicht weiter.

Im Frontend möchte ich kein Ajax/jQuery benutzen, damit würde es wahrscheinlich gehen. (aber nur wenn ich die Page periodisch aufrufe)
Meine Frage betrifft rein die Aktualisierung durch das Frontend.

Also der Wert in der SPS ändert sich unregelmäßig und im Frontend soll dies in einem <div> angezeigt werden. Das ist schon alles.
Geht das irgendwie?

Eine Idee wäre, eine Partialpage einzubinden, welche das div-Element enthält und dieses dann from Backend aus zu aktualisieren?
Ich möchte keinesfalls die komplette Seite aktualisieren und auch nicht mit Javascript etc. vom Frontend aus periodisch eine Backendfunktion aufrufen, die die Node auf Veränderung prüft usw.
Impulsgeber soll das Backend sein und nur bei Veränderung die Aktualisierung anstoßen.
Eigentlich denke ich, dass das nicht geht...aber vielleicht ja doch?

Danke und schönen Abend, Euch

16.807 Beiträge seit 2008
vor einem Jahr

Sowas geht mit sogenannten WebSockets; nicht direkt mit HTTP. HTTP ist zustandslos und nach der Server-Antwort ist die Verbindung abgeschlossen.
WebSockets sind aber bidirektionale TCP Verbindungen, mit denen Du Server Push umsetzen kannst.
Im .NET Umfeld gibts dafür SignalR, was mittlerweile ein Teil (Middleware) von ASp.NET Core ist.

Übersicht über ASP.NET CoreSignalR

D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr

Moin und Danke auch.
Hm, damit habe ich schon mal gefummelt, es war dann nur so, dass es irgendwann mal nicht mehr aktualisiert wurde.
Sei es nach Tagen oder nach Monaten.
Naja, vielleicht habe ich das auch falsch implementiert.
Werde es nach der Anleitung nochmals versuchen und g'scheit machen.

Aber dann ist es schon so, dass es rein vom Backend aus nicht wirklich geht...immerhin.

Also danke nochmals und frohes Arbeiten.

16.807 Beiträge seit 2008
vor einem Jahr

Ich bin auch im Maschinenbau tätig, machen viel mit OPC und dessen Varianten.
Das geht aus dem Backend, das geht mit WebSockets. Sehr stabil, auch über Monate.
Sowohl für kleine Steuerungen wie auch für sehr große Industrie-Anlagen.

D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr

Prima, vielen Dank.
Dann habe ich das wohl nicht gescheit implementiert.

Im Moment scheitere ich an einer wohl einfachen Sache, Namens Cors.
Zwar habe ich mich belesen und Quellcode getestet, trotzdem geht es in meiner kleinen, lokalen Client-Serverumgebung nicht.

Folgendes:
Client- und Serveranwendung ist ein von MS bereitgestelltes Sampleprojekt.

Client ist ein einfacher JavaScriptclient:


document.addEventListener("DOMContentLoaded", () => {
    const connection = new signalR.HubConnectionBuilder()
        .withUrl("https://localhost:60500/Chat")
        .build();

Wie hier ersichtlich ist, läuft der Server auf locahlost:60500, der Hub auf "chat".
Da es einen Domänenübergreifender Prozess ist, muss ich ja auf dem Server CORS aktivieren:




builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(
        builder =>
        {
            builder.WithOrigins("https://localhost:7056")           
                .AllowAnyHeader()
                .AllowAnyMethod()
                //  .WithMethods("GET", "POST")
                .AllowCredentials();
        });
});


Also der Server startet mit https://localhost:60500/
und der Client mit https://localhost:7056/

D.h. ich muss https://localhost:7056/ auf dem Server erlauben.
Fehlermeldung im Client:

Fehlermeldung:
Access to fetch at 'https://localhost:60500/Chat/negotiate?negotiateVersion=1' from origin 'https://localhost:7056' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
...
POST https://localhost:60500/Chat/negotiate?negotiateVersion=1 net::ERR_FAILED

Origin ist ja https://localhost:7056, dieser wird im Server zugelassen.
Der Client verweist auf die direkte Domain https://localhost:60500/Chat.

Also alles wie von MS beschrieben, trotzdem geht es nicht.
Lt. Fehlermeldung fehlt noch ein Header im Client? (No 'Access-Control-Allow-Origin' header is present on the requested resource)

Ich muss dazu auch sagen, dass ich im Client das NugetPackage Microsoft.AspNetCore.SignalR nutze, welches als veraltet gekennzeichnet ist.
Welches sollte man stattdessen nutzen?

16.807 Beiträge seit 2008
vor einem Jahr

Die Sicherheitsaspekte eines Endpunkt im Internet bzw bei Browsern beziehen sich auf die Kombination DNS/IP Port und Protokoll.
Dein CORS-Setup beinhaltet den SignalR Endpunkt nicht, was aber beinhaltet sein muss.

Überlicherweise lässt man SignalR eh nicht auf einem eigenen Port laufen, sondern auf einer Route.


   app.UseCors(builder =>
    {
        builder.WithOrigins("https://myhost:port")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<MyHub>("/myHub"); // https://myhost:port/myHub
    });

Welches sollte man stattdessen nutzen?

Mach doch einfach mal das Tutorial durch, das in den Docs beschrieben ist.
Dort wird die neueste Variante inkl. Einrichtungserklärung gezeigt. Die Docs gibts ja nicht umsonst, die sparen Dir Zeit und erklären Dir Dinge.
Darf man ruhig nutzen 😉

Übersicht über ASP.NET CoreSignalR

D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr

Den Endpunkt definiere ich doch mit


app.MapHub<ChatHub>("/ChatHub");

Also es geht lokal jetzt mal. (reimt sich)
Hatte AllowCredentials() nicht dazugefügt....keine Ahnung für was man das braucht 🙂

Vielen Dank für Deine Hilfe.

16.807 Beiträge seit 2008
vor einem Jahr

Den Endpunkt definiere ich doch mit

Die Fehlermeldung zeigt einen anderen Endpunkt.> Fehlermeldung:

Access to fetch at 'https://localhost:60500/Chat/negotiate?negotiateVersion=1


 builder.WithOrigins("https://localhost:7056")

Das sind zwei Endpunkte, unterschiedliche Ports.

Hatte AllowCredentials() nicht dazugefügt....keine Ahnung für was man das braucht

Wenn man etwas nicht weiß, dann kann man das nachlesen, sodass man was dazu lernt.
Security considerations in ASP.NET Core SignalR

Flapsig ausgedrückt: wenn man mit einer fremden Technologie nur rumstochert, statt nachzulesen und zu verstehen wie sie funktioniert, wirds ganz arg schwer mit einer stabilen Lösung 🙂

D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr

Ein bischen Flaps vertrage ich schon 🙂
Na also inzwischen geht es, vielen Dank für Deine Hilfe!

16.807 Beiträge seit 2008
vor einem Jahr

Top, das heisst Du hast das nun also mit SignalR lösen können?

D
DerBeginner Themenstarter:in
8 Beiträge seit 2022
vor einem Jahr

Jawollo!
Habe einen 1A SignalR Selfhosted Websocket aufgesetzt mit automatischem Reconnecting... 👍