Laden...

Antwort aus Programm herraus

Letzter Beitrag vor 2 Jahren 9 Posts 333 Views
Antwort aus Programm herraus

Hallo liebe Mitentwickler,

ich arbeite gerade an einem flexiblen Serversystem und möchte wissen ob die folgende umsetzung möglich ist.

Mein Server soll in der Lage sein, anfragen aus dem Internet (egal ob vom Handy, Tablet, PC oder what ever) aufzunehmen und zu verarbeiten. (Funktioniert auch). Nun soll er aber flexibler werden. Ich möchte nun Mehrere Serverinstanzen auf verschiedenen Ports starten (funktioniert auch) und die empfangenen Daten jedoch underschiedlich behandeln. Dazu Soll jeder Server ein jeweils eigenes Programm aufrufen, die daten übergeben und (jetzt kommt der casus knacksus) dieses Programm soll die Antwort an den Server zurückgeben und dieser an den Client zurücksenden.

Die eigentliche Client Server Communikation funktioniert auch.
Im Internet habe ich die Methode "RedirectStandartOutput" gefunden welche (so die quelle) die Antwort als Consle.WriteLine(); an den Server zurückgeben soll


_serverOperate.StartInfo.FileName = _operationAppPath; // enthält den Path des Programms welches die eigentliche Verarbeitung durchführt und die antwort an den Client ausgibt (Soll vom Server aufgerufen werden und nach der Antwortausgabe wieder geschlossen werden)
                    _serverOperate.StartInfo.Arguments = ""+DBHost+";"+DBName+";"+DBUserName+";"+DBUserPassword+";"+content; // content enthält einen JSon string
                    _serverOperate.StartInfo.UseShellExecute = false;
                    _serverOperate.StartInfo.RedirectStandardOutput = true;
                    StreamReader reader = _serverOperate.StandardOutput;
                    string output = reader.ReadToEnd();
                    Send(handler, output); // sendet die daten an den Client zurück

Ich bekomme jedoch eine Exeption ausgegeben > Fehlermeldung:

"System.InvalidOperationException: StandartOut wurde nicht Umgeleitet, oder der Prozess wurde noch nicht gestartet."

Nun ist meine Frage: Leide ich an Programmierblindheit oder ist das so wie ich das umsetzen möchte gar nicht möglich und och habe die Methode falsch verstanden?

Vielen Dank im Vorraus

Die Meldung klingt danach, dass du die StartInfo zwar füllst aber das Programm nicht startest.
Dadurch knallt es auch, da du einen Stream lesen willst, der gar nicht geöffnet werden kann, da das Programm nicht läuft.

Doku:
https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.processstartinfo?view=net-6.0
https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.process?view=net-6.0

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Danke T-Virus,

das ".Start()" habe ich übersehen. Aber ändert leider das Problem nicht. Der gleiche fehler tritt auf.
ich habe das zwischen StreamReader oder StandartOutput geschrieben.

Obwohl ich schon viel gesehen hab, wunder ich mich doch immer wieder, wieso Entwickler:innen denken, dass so eine Umsetzung eine gute oder gar sichere Idee sei.


_serverOperate.StartInfo.Arguments = ""+DBHost+";"+DBName+";"+DBUserName+";"+DBUserPassword+";"+content;

Also, im Ernst? Und wir wundern uns über unsichere Software, GDPR-Verstöße und Datenverluste...
Naja, wie dem auch sei.

Wir kennen hier die Bedingungen nicht, wie diese "Server App" gestartet werden muss.
Vermutlich fehlen noch Settings, wie zB Shell Execute, oder CreateNoWindow etc... oder die Anwendung startet eben gar nicht.

Dein Code funktioniert nur bei Aufrufen, die korrekt starten und sofort ein Ergebnis liefern.
Bei Delay der Ausgabe muss man entweder

  • auf das Programmende warten (WaitForExit)und kann dann ReadToEnd() verwenden
    oder
  • muss in einer Schleife die Ausgaben, die sich aktuell in StdOut über ReadLine() abfragen, bis das Programm beendet wurde.

Siehe Docs.

@Abt,

zunächst Danke ich dir für deine (wenn auch sehr kritisch formulierte) Antwort. Ich bin aber sicher, dass du diese nicht als persönlichen Angriff meintest daher werte ich dies auch nicht so.

Zum Thema Sicherheit: Du hast Recht! Diese weise der Programmierung ist sehr unsicher. Stell dir vor, die Daten werden sogar unverschlüsselt übertragen 😉 und das hat seinen Grund!
Die Anwendung bildet ersteinmal nur das Grundgerüst. Das Fundament sozusgen. Sie ist rein Experimentell (noch). Erstmal soll alles im Grundprinzip funktionieren. Der Ausbau und die Sicherheit kommt erst dann in den eigentlichen Testphasen und bis dahin ist es noch ein sehr sehr weiter weg. Zudem soll sie ohnehin nur für meine Privaten zwecke verwendet werden und keine Nutzerdaten übers Inet transportieren.

Die Bedingungen zum aufrufen der arbeitsanwendung stehen doch da!
Bei einer Clientanfrage empfängt der Server die Daten, öffnet das programm und leitet die Daten an das Programm weiter; anschließend wartet der Server auf die Antwort des Programms und sendet die antwort zurück an den client. das Programm schließt sich automatisch nach der abarbeitung und wird immer nur aufgerufen wenn ein Client eine anfrage sendet!

lg

Korrekt, ist rein (frustriert) sachlich.

Der Ausbau und die Sicherheit kommt erst dann in den eigentlichen Testphasen und bis dahin ist es noch ein sehr sehr weiter weg.

Security ist Teil des Grundkonzepts, kein Feature.
Steht übrigens so auch in den "BSI Richtlinien für sichere Software Entwicklung". Zudem kann nachträgliche Security dazu beitragen, dass Dein gesamtes Grundkonzept umgebaut werden muss.
Ich hatte jetzt erst so ein Fall, der mich 2 Wochen gekostet hat, ein DevOps Szenario für Datenbanken von Basic Auth auf Managed Identities zu ändern: das gesamte Kommunikations- und DevOps Konzept wurde ausgetauscht. Das ist kein Bauklotz, das ist ein Fundament.
Daher ist "nachträgliche Security" ein Fehlkonzept.

Die Bedingungen zum aufrufen der arbeitsanwendung stehen doch da!

Ne, da stehen logische Bedingungen, keine technischen.

Eine Console App ist nicht gleich eine Console App.
Es gibt synchronen Output, und asynchronen Output einer Console App, und das muss unterschiedlich umgesetzt werden.

  • Synchron: kannst via ReadToEnd blocken
  • Asynchron: i.d.R. über Handler (oder blockierend über Schleifen)

Hinzu kommt, dass die Startparameter einer Console App relevant sein können, zB Working Directory etc.
Das sehen wir alles nicht. Wir sehen hier nur die Symtpome; und die sehen so aus, dass a) Du den Output falsch behandelst oder b) die App gar nicht erst startet.

@Abt,

wie meinst du das mit den technischen Bedingungen?

"Wie muss die Console App gestartet werden."

Und ganz wichtig, warum muss eine Console App gestartet werden?