CruzZer schrieb:

Ich würde gerne eine Verbindung zu einer MySQL Datenbank (PHPMyAdmin) herstellen und dort Einträge erstellen und bearbeiten.

Das ist keine gute Idee.
Besser ist, im Client ein lokales Datenmodell vorzuhalten, zu befüllen, dort bearbeiten, und anschließend die Änderungen rückzuspeichern.

Weil wenn du Einträge in der DB änderst, siehst du als User nix davon.
Bzw du musst nach jeder Änderung die Daten neu abrufen, was ja ein erheblicher Unsinns-Traffic wäre.

Bist du einverstanden mit diesem Konzept?
Dann brauchst du - bevor du überhaupt irgendwas von deine DB abrufen kannst - erstmal das lokale Datenmodell im Client.

Das kann man entweder als typisiertes Dataset vorhalten oder als EntityFramework-Datenklassen.
Wobei ich nicht weiß, wie mehr oder weniger umständlich EF mit MySql zusammenarbeitet.

Meine Lieblings-Vorgehensweise geht vom typDataset aus, was man ganz ohne Datenbank entwickeln kann: Daten laden und speichern, sowie vier Views-Videos und weiteres.
Späterhin kann man auch eine beliebige Datenbank hinterlegen, sogar austauschbar - je nachdem, was im ConnectionString steht, und was als DbProviderFactory angegeben wird.

Aber solch erst späterhin, denn das ist kompliziert - obwohl im Vergleich mit anderen noch die einfachste Möglichkeit ist.

Hier noch ein Hinweis, wie mans auf keinen Fall machen darf (und wie leider trotzdem 99% aller Anfänger anfangen): Sql-Injection

CruzZer schrieb:

Ich würde gerne eine Verbindung zu einer MySQL Datenbank (PHPMyAdmin) herstellen und dort Einträge erstellen und bearbeiten.

Brauchst du jetzt eine Bedienungsanleitung zu phpMyAdmin oder möchtest du die DB an dein Programm binden und damit die Daten modifizieren?

​Besser ist, im Client ein lokales Datenmodell vorzuhalten, zu befüllen, dort bearbeiten, und anschließend die Änderungen rückzuspeichern.

Das ist nur dann eine gute Idee wenn du das ganze im Internen Netzwerk verwendest oder (solltest du online gehen) genau weist wem du das Programm später aushändigst. Anderenfalls ist eine direkte Kommunikation mit dem MySQL Server eine grobe Sicherheitslücke, die die MySQL Server mit Standarteinstellungen gar nicht mit machen. Normalerweise sind die nämlich so eingestellt, das sie von nickt lokalen quellen keine Befehle entgegennehmen.

Das ganze hat den Hintergrund, das im Programm bei einem direkten Zugriff auch Benutzername und Passwort zu deinem Datenbankserver hinterlegt sind. Damit kann man dann auch sehr einfach Schindluder treiben. Deutlich sicherer wäre da der Umweg über PHP oder wenn du einen Windows Server benutzt ein eigenes Serverprogramm, dass dann Datenbankseitig so arbeitet wie EdR es bereits beschrieben hat.

hmm?
Das Vorhalten eines ordentlichen Datenmodells hat doch mit Sicherheit gegenüber Angreifern nix zu tun.
PHP-Kommunikation lässt sich übrigens ebensogut abhören wie Standard-MS-Sql-Kommunikation.
Also Kommunikation übers Internet muss per SSL erfolgen - egal ob Php verwendet wird oder Db-Kommunikation.

Stimmt aber das abhören der Kommunikation mit PHP gibt mir nicht gleich lese und Schreibrechte in der db.

Wenn ich das Datenmodell lokal vorhalte um Änderungen an den Server zurück zu geben MUSS ich zwangsläufig Benutzername und Passwort für die Datenbank in der Anwendung hinterlegen. Damit brauche ich auch nichts mehr abhören. Ich hole mir Benutzername und Passwort direkt aus der Anwendung und schicke dann lustig meine eigenen Querys.

Der Umweg über PHP ist insofern sicherer, dass ich wenn das ganze PHP seitig vernünftig programmiert wurde ich dennoch keine willkürlichen Querys verwenden kann. Sondern mich immer genau an das Muster halten muss das auch das Programm zur Kommunikation benutzt.

Klar kann man auch damit Schindluder treiben aber man ist deutlich eingeschränkter

Immer natürlich davon ausgehend, das man keine fertigen Querystrings an das php Script übergibt.

jo - stimmen wir also überein: Php schränkt die Angriffs-fläche ein auf vorgegebene Methoden (wenn richtig gecodet).
Sodass ein Angreifer nur diese Methoden missbrauchen kann, nicht aber frei formuliertes Sql absetzen.
Solche Php-Schichten kann man auch als Proxy auffassen.

Aber abhörbar und missbrauchbar ists nachwievor.
Und so einen Proxy kann man imo besser mit DB-Bordmitteln implementieren, also mit StorecProcs im SqlServer.

Wie gesagt: Das Datenmodell im Client hat nix damit zu tun - das wird nur befüllt, und natürlich hofflich nicht mittels eines hardcodierten Passwortes im Quellcode.
Das Client-Datenmodell müsste man ebenso auch per Php befüllen (was allerdings wesentlich umständlicher wäre, denn Php kann nur String-Datentypen transportieren).

Korrigier mich bitte, was die letzte, geklammerte Bemerkung betrifft. Weil praktische Php-Erfahrung habichnich.

Natürlich muss man auch im PHP Fall Methoden wie SSL einsetzen. Neben SSL beherrscht php aber auch noch alle anderen gängigen Verschlüsselungsfunktionen so könnte man beispielsweise sein Kommando für das php Script mit AES verschlüsseln oder (und) SSL benutzen. Das erhöht den Aufwand für einen Angreifer dann doch enorm.

Schöner ist es natürlich mit einem typisierten Dataset zu arbeiten und sauberer ist es obendrein.

Verschlüsselte Kommunikation und StorecProcs scheint eine gut Alternative zu einem PHP Script zu sein sofern ich den Datenbankbenutzer so konfigurieren kann, das er nur diese gespeicherten Prozeduren ausführen darf. (Dafür fehlt mir die Erfahrung weil ich nur im internen Netzwerk arbeite).

Was die Anmeldeinformationen angeht wäre interessant zu wissen wie ich im Visual Studio vorgehen muss damit er die Verbindungsinformationen eben nicht im Klartext mit kompiliert

was allerdings wesentlich umständlicher wäre, denn Php kann nur String-Datentypen transportieren

Stimmt php gibt HTML Text aus und das ist zwangsläufig ein String den man dann entsprechend zerlegen und konvertieren müsste. Was wieder fehleranfällig und kompliziert ist

Theoretisch könnte ein PHP Script auch eine xml Datei erzeugen die man dann herunterladen und in ein Dataset einlesen könnte. Das ist aber PHP seitig mühsam.

Ihr habt aber schon mitgekriegt, dass es um phpMyAdmin geht?
Das ist ein in PHP geschriebenes Remote GUI für MySQL, das über HTTPS arbeitet (falls man nicht HTTP explizit forciert).
In der Funktionalität grob vergleichbar mit dem SQL Server Management Studio.

Ich persönlich arbeite zwar bei MySQL lieber über die Workbench, aber wenn man lokal nichts installieren will oder Firewall-Restriktionen hat, ist phpMyAdmin extrem nützlich.

Ein bisschen Off topic: wie wäre egtl die Idee die Daten direkt über eine vpn Verbindung (zB mit einer software vpn die heute durchaus bezahlbar zu haben ist) zu übertragen? Also den Usern auf zu erlegen dass ein externer Datenzugriff (egal ob xml via dataset oder sql dB) lediglich über vpn realisiert werden darf? Heute hat man doch im geschäftsalltag für alles mögliche vpn Tunnel...

hans im glück schrieb:

Ein bisschen Off topic: wie wäre egtl die Idee die Daten direkt über eine vpn Verbindung (zB mit einer software vpn die heute durchaus bezahlbar zu haben ist) zu übertragen? Also den Usern auf zu erlegen dass ein externer Datenzugriff (egal ob xml via dataset oder sql dB) lediglich über vpn realisiert werden darf? Heute hat man doch im geschäftsalltag für alles mögliche vpn Tunnel...

was sagen die experten zum thema zugriff auf kleine sql db oder xml per vpn? keiner eine meinung?

VPN Tunnel kann man völlig gebührenfrei zwischen zwei Geräten selbst aufstellen. Aber VPN dafür? Nope nope und nochmal nope. Zudem völlig OT bis sich der TE meldet und dazu etwas sagt.
Edit: WCF-Service mit TLS absicherung. Is fix, sicher und in C#/VB geschrieben.

hans im glück schrieb:

zugriff auf kleine sql db oder xml per vpn

Wenn der DB-Server VPN unterstützt (oder das ein eigener Server ist, den man selbst modifizieren kann), ist das zumindest serverseitig machbar.
Dann ist die Frage, ob das VPN client-seitig vom Enduser-Rechner selbst oder von einem zentralen Netzwerkrechner abgewickelt werden soll.
Jedenfalls ist in einem grösseren Unternehmen VPN immer ein Kugelfuhr, da in der Regel die Kommunikation über zu viele Leute geht, die die Zusammenhänge nicht kapieren.

Da ist es ein Segen, wenn (wie im vorliegenden Fall) der DB-Provider phpMyAdmin anbietet, da dann alles über HTTPS abgewickelt werden kann.