PHP Seite um in MySQL zu schreiben

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:
> 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.

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...