Guten Tag, ich suche eine simple und gute Methode um per CodeSys von einer Berghof SPS aus in eine MySQL Datenbank zu schreiben. Mein Ansatz wäre eine PHP Seite in deren URL Parameter mit gegeben werden die dann von PHP in die Datenbank schreibt. Meine Linux Kenntnisse sind gering. Meine aber mich zu erinnern das es mit ´dem Befehl Wget möglich ist eine URL aufzurufen. Was meint ihr zu meiner Idee? Danke für Eure Meinung. PS wäre dieser Weg Sicher oder sehr gefährlich?
Gefährlich ist das nicht, wenn Du die Datenübertragung authentifizierst und verschlüsselst (vor allem die Authentifizierung). Dabei müssen die Daten auch von evtl. schädlichem Inhalt (MySQL-Injection) befreit werden. Dann ist das eine der einfachsten Möglichkeiten, im Internet Daten eine ein MySQL-Datenbank zu bekommen.
Fluke schrieb: > ich suche eine simple und gute Methode um per CodeSys von einer Berghof > SPS aus in eine MySQL Datenbank zu schreiben. > > Mein Ansatz wäre eine PHP Seite in deren URL Parameter mit gegeben > werden die dann von PHP in die Datenbank schreibt. was befindet sich denn zwischen der sps und dem db-server? läuft die kommunikation "nur" über ein internes netzwerk, haben die zwei kisten sogar ein eigenes, abgeschottetes netz, oder läuft die übertragung über das internet?
Ben B. schrieb: > schädlichem Inhalt (MySQL-Injection) befreit Was heißt das konkret? diensthabender quotendepp schrieb: > was befindet sich denn zwischen der sps und dem db-server? läuft die > kommunikation "nur" über ein internes netzwerk, haben die zwei kisten > sogar ein eigenes, abgeschottetes netz, oder läuft die übertragung über > das internet? Das Ganze würde über einen VPN Tunnel passieren Wie ist das mit Wget? Danke für Eure Hilfe.
Fluke schrieb: > Ben B. schrieb: >> schädlichem Inhalt (MySQL-Injection) befreit > > Was heißt das konkret? Das ist eigentlich noch die kleinste Hürde. SQL-Injection bedeutet, dass ein Angreifer über den Weg der Parameterübergabe SQL Anweisungen an Deine Datenbank senden kann. Nehmen wir mal an, du würdest auf einfachste Weise eine Variable in eine Datenbank schreiben, z.B. mysql_query("UPDATE tabelle SET spalte = $VARIABLE"); Und wenn $VARIABLE einfach nur den Übergabeparameter Deines Requests enthalten würde, dann wäre es ein leichtes, SQL zu injezieren... z.B. wenn der requestparameter so aussieht: $VARIABLE = "Neuer Wert\"; truncate tabelle;" ... denn dann wäre Deine Tabelle anschließend leer. Aber wie gesagt, dafür bietet PHP bereits ausreichend Methoden. Ob ein VPN allein ausreichend Schutz bietet, kommt auf Deine Umgebung an. Aber auch da gibt es Möglichkeiten. Z.B. könntest Du den Webserver so konfigurieren, dass er einen Request nur von einem bestimmten Client zulässt. Oder man verwendet ein Zertifikat zur Authentifizierung. Eine HTTP-Authentifizierung bringt auch Sicherheit. Aber grundsätzlich geht das schon, so wie Du es vor hast. [SPS]----> <wget --post-data "parameter=wert" URL> ---(VPN-Tunnel) ---> Webserver ----> <PHP Skript> ----> Datenbank
Andi schrieb: > SPS]----> <wget --post-data "parameter=wert" URL> ---(VPN-Tunnel) ---> > Webserver ----> <PHP Skript> ----> Datenbank Danke für die Ausführliche Antwort. Das VPN ist mit Zertifikat zur Authentifizierung. Wie ist es mit wget? Wird da immer die Seite downloadet? Wie muss ich den Wget Befehl schreiben?
Fluke schrieb: > Wie ist es mit wget? Wird da immer die Seite downloadet? "Die Seite"? Also sinnvollerweise gibt Dein PHP Skript am anderen mindestens einen HTTP Statuscode zurück, da mit wget clientseitig auch mit einem Erfolgstatus beendet wird. Wie der Aufruf erfolgt suchst Du Dir am besten hier zusammen: https://www.gnu.org/software/wget/manual/html_node/index.html Das kann Dir hier niemand sagen, weil keiner Deine Umgebung kennt...
Fluke schrieb: > Weinbauer schrieb: >> $_GET >> mysqli_realescape_string >> $_SERVER > > was meinst du damit? das sind stichworte, um die suchmaschine des geringsten misstrauens damit zu füttern. oder einfach php.net, das liefert die gleichen informationen.
Daniel F. schrieb: > das sind stichworte, um die suchmaschine des geringsten misstrauens > damit zu füttern. oder einfach php.net, das liefert die gleichen > informationen. Lach "misstrauens" Danke
Fluke schrieb: > mysqli_realescape_string O gott nein, lasst den Blödsinn! Nehmt lieber prepared statements, statt da selbst was zusammenzubasteln. https://www.php.net/manual/en/mysqli.prepare.php Wobei, von mysqli würde ich auch abraten, nehmt PDO, dann kann man später einfacher auf andere DBs wechseln. https://www.php.net/manual/en/book.pdo.php
Jetzt fängt der Formatkrieg wieder an... wir sind alle verloren!
Fluke schrieb: > ich suche eine simple und gute Methode um per CodeSys von einer Berghof > SPS aus in eine MySQL Datenbank zu schreiben. > > Mein Ansatz wäre eine PHP Seite in deren URL Parameter mit gegeben > werden die dann von PHP in die Datenbank schreibt. > > Meine Linux Kenntnisse sind gering. > Meine aber mich zu erinnern das es mit ´dem Befehl Wget möglich ist eine > URL aufzurufen. Im Prinzip kannst Du mit jeder Skriptsprache in die meisten Datenbanken schreiben. Meine persönliche Wahl wären zwar Elasticsearch und curl, aber da geht es primär um Geschmack und Erfahrung -- außer beim Elasticsearch, das hätte nämlich womöglich ein paar grandiose Vorzüge. Einer davon ist, daß Elasticsearch direkt mit JSON-Daten beschickt werden kann und Du dann keine Zeile Code auf der Linuxmaschine schreiben müßtest. Ein anderer ist, daß es für Elasticsearch mit Kibana eine sehr leistungsfähige Webapp zur Exploration, Analyse und Visualisierung der Daten gibt. Wenn Du ohnehin wenig Erfahrung außerhalb von CodeSys hast und so wenig eigenen Code wie möglich schreiben willst, ist das IMHO ein viel besserer Ansatz. Wenn Du magst, helfe ich Dir gerne bei den ersten Schritten... ;-) > PS wäre dieser Weg Sicher oder sehr gefährlich? Das ist im Grunde die wesentlich schwierigere Frage -- zumal Du nicht sagst, was Du mit "sicher" meinst, denn Sicherheit hat viele Aspekte. Der erste ist das, was die meisten Menschen ad hoc unter Sicherheit verstehen: können dort vorhandene Daten abgehört, manipuliert, oder gelöscht, oder womöglich auch falsche Daten injiziert werden? Fangen wir einfach mal mit diesem Aspekt der Datenveränderung an. Um zu verhindern, daß nur derjenige die Daten schreiben darf, der dazu authorisiert ist, braucht es mindestens drei Dinge: die Authentifizierung, welche sicherstellt, daß jeder der beiden Kommunikationspartner derjenige ist, für den er sich ausgibt -- sowas kennen die meisten, wenn sie sich mit Benutzernamen und Paßwort an einer Webseite wie diesem Forum anmelden -- sowie einer Autorisierung, die im zweiten Schritt sicherstellt, daß der so authentifizierte Benutzer nur auf das zugreifen darf, was ihm erlaubt ist. Dritter Schritt wäre dann die Plausibilisierung, welche überprüft, ob die eingelieferten Daten die erwarteten Datentypen und Wertebereiche haben, um zu verhindern, daß eine wildgewordene Datenquelle den Datenbestand mittels unsinniger Daten invalidiert. Ein weiterer Aspekt ist die Verfügbarkeit der Daten, mit Monitoring und Backups und solchen Dingen. Das Gesetz vom guten alten Murphy sagt, daß alles schiefgeht, was schiefgehen kann -- und aus der Erfahrung kann ich Dir sagen: Murphy hat Recht, genau so ist es. Was passiert, wenn Dein Server rebootet werden muß und daher für einen gewissen Zeitraum keine weiteren Daten entgegennehmen und speichern kann? Was ist, wenn das bei Deiner SPS passiert, und sie keine Daten liefern kann? Es gibt da eine ziemlich umfangreiche Reihe von Dingen, die man tun kann, angefangen bei einer Pufferung der Daten auf der SPS, bis der Server bestätigt hat, daß sie korrekt in die Datenbank geschrieben wurden, bis hin zu einer echten Hochverfügbarkeitslösung -- das hängt davon ab, wieviel Datenverluste Du bei einem desaströsen Problem akzeptieren kannst. (Auch hier könnte ein Elasticsearch ein paar Vorteile bieten, weil es bereits eine eingebaute verteilte Clusteringlösung mitbringt.) Je nach Deinen Anforderungen ist womöglich auch ein Monitoring notwendig, das die Software selbst (Laufen die Prozesse? Funktioniert ein Heartbeat? etc...), die Logdateien und die Daten überwacht und Dich alarmiert, wenn irgendwas schiefläuft... und das kratzt nur an der Oberfläche, dazu kann man viele Dutzend Seiten lange Abhandlungen und, sogar wenn man auf eine etablierte Standardlösung wie Zabbix, Icinga, Elasticsearch (ja, wieder, diesmal aber mit kommerziellen Erweiterungen), Opsgenie oä. setzt, viele tausend Zeilen Software für Agenten, Loganalyse, Heartbeat, Reporting und so weiter schreiben. Letzten Endes beginnt aber alles mit der Definition Deines Anwendungsfalls und einer darauf basierenden Risikoanalyse. Leider sagst Du aber gerade dazu nicht sehr viel, insofern es sicherlich hilfreich wäre, zu sagen: was für Daten möchtest Du denn sammeln, und wozu sollen sie benutzt werden? Sind die Daten im Fehlerfall reproduzierbar? Hast Du ein finanzielles oder zeitliches Budget, das einzuhalten ist?
DPA schrieb: > Fluke schrieb: >> mysqli_realescape_string > > O gott nein, lasst den Blödsinn! Nehmt lieber prepared statements, statt > da selbst was zusammenzubasteln. > https://www.php.net/manual/en/mysqli.prepare.php > > Wobei, von mysqli würde ich auch abraten, nehmt PDO In PHP Doctrine, in Perl Class::DBI, in Python SQLObject oder SQLAlchemy... Für alles außer High-Performance ist ein OR-Mapper immer die bessere Wahl, und auch aus den genannten Frameworks kann man jederzeit den DB-Handle oder eine Connection aus dem Pool bekommen und natives Zeug machen. Das ist dann zwar womöglich nicht portabel zu anderen Datenbanken, reduziert jedoch die zu ändernden Stellen auf ein Minimum. Ansonsten ist pgFouine immer ganz nett, wenn man wissen will, welche Query wie oft und wie lang auf einer PostgreSQL-Datenbank läuft und wo man daher sinnvollerweise mit Optimierungen ansetzt -- wenn man sowas denn ernsthaft optimieren muß, für überschaubar große und periodisch anfallende Meßdaten reicht ja vermutlich sogar SQLite...
Sheeva P. schrieb: > von > > Sheeva Danke für deine Super Erklärung und dein Angebot. Ich werde mal Prüfen was ich genau brauche. Werde dann gegebenen Fall auf dein Angebot zurück kommen Danke
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.