PHP-Schnittstelle zur Datenbank

[sparrow]

Guten Morgen!

Ich möchte ein von mir erstelltes Applet auf eine Datenbank zugreifen lassen, und dabei den Weg über eine PHP-Datei nehmen um die maximale Sicherheit zu gewährleisten.

Dummerweise hab ich von PHP überhaupt gar keine Ahnung ... *g*

Alles was meine PHP-Datei können muss:

Aufruf aus dem Applet als Webseite, empfangen des SQL-Befehls (wahrscheinlich während des Aufrufens als Parameter übergeben??), ausführen des SQL-Befehls (natürlich vorher Datenbank konnekten) und das Ergebnis ans Appelt zurücksenden (Wahrscheinlich als Antwort auf den ursprünglichen Seitenaufruf des Applets).


Ich bin nicht so dreist und frage nach einem kompletten Code, aber kann mir vielleicht jemand weiterhelfen, ob es im Netz ein feines Tutorial gibt?
Der ganze Rest von PHP interessiert mich ehrlich gesagt recht wenig, es geht tatsächlich nur darum eine Schnittstelle einzurichten.

Ich danke euch im Voraus!

 

[Bleiglanz]

such mal im forum nach Applet und PHP, war alles schon mal da

 

[sparrow]

Ok, ich suche mal ein bisschen,
bisher hab ich nur Beispiele für den Teil gefunden der in Java umgesetzt wird.
Mit dem hab ich ja auch keine Probleme... nur mit dem PHP-Code.
Werd schon was finden ;-)

Danke!

 

[AlArenal]

Sowas wäre ja toll.. da schicke ich dener PHP-Seite einfach mein SQL per Browser-URL-Zeile und erhalte alles was ich will aus der DB im Browser als Text angezeigt. Ob das nun wirklich die Sicherheit erhöht?

Wir machen sowas hier per XML-RPC. Problem von XML-RPC (ebenso wie SOAP) ist
1. Das Verpeacken der Daten in XML bläht alles stark auf (Traffic, Übertragungsgeschwindigkeit).
2. Wird keine SSL-Verbindng genutzt, erfolgt die Übertragung im Klartext.

Derzeit stelle ich daher Überlegungen für ein eigenes Open Source Projekt an, um XML-RPC (und zwar die JAva-Lib von apache und das PEAR-Package für PHP) um Funktionen zur Kompression und Verschlüsselung der Daten zu erweitern.

 

[Bleiglanz]

Sowas wäre ja toll.. da schicke ich dener PHP-Seite einfach mein SQL per Browser-URL-Zeile und erhalte alles was ich will aus der DB im Browser als Text angezeigt. Ob das nun wirklich die Sicherheit erhöht?

na, zumindest die Anmeldeinformationen für die DB bleiben auf dem Server

Problem ist natürlich, dass die SQL Strings viel über die DB-Struktur verraten würden, besser wäre es, nur noch eine ID für die "Abfrage" und die Parameter zu schicken [also auch die SQL-Statements auf dem Server zu lassen]

 

[AlArenal]

Es bliebe m.E. dennoch Flickwerk. Ich muss dann serverseitig für jedes Statement eine ID pfelgen und diese im Client ebenfalls mitführen. Dann muss ich auch im Client ne Liste haben welches Statement Daten von welchem Aufbau zurückliefert (alles kommt ja als Text zurück).

Ändere ich eine Abfrage oder die Tabellenstruktur (SELECT * FROM xy liefert nun 5 statt 4 Spalten), muss ich meine Meta-Information und meine Daten-Umpack-Klasse abändern...

Da nehme ich lieber gleich XML-RPC oder SOAP. Da baue ich wenigstens auf einem Standard auf, bin varaibler was zusätzliche Anbindungen angeht und und und

Für solche Zwekce wurde der Krims schließlich mal erdacht.

 

[sparrow]

Es will mir eh nicht in den Kopf warum Java bei Datenbanken... nun ja, so unsicher scheint.
An sich ist die Sprache optimal dafür geeignet um zum Bau von Front-Ends verwendet zu werden.
Das bauen von GUIs und das Ansprechen einer SQL-Datenbank ist auch supereinfach...
und dann ist da noch diese Sache das sich ein Java-Programm sehr schnell decompilieren läßt...
Herje, teilweise kann man die Strings ja sogar in der Klasse mit einem Editor sehen.

Da es nun aber ein Applet werden soll muss ich da wohl irgendwo in den sauren Apfel beißen, oder aber mit etwas anderes einfallen lassen.

Prinzipiell suche ich eine Methode die es ermöglicht SQL unter Java zu benutzen, ohne dabei zu große Sicherheitslöcher zu reißen. Vielleicht finde ich ja noch eine Möglichkeit.

SOAP kommt für mich nicht in Frage.
Da es sich um eine Datenbank handeln wird auf der u. U. sehr viel Bewegung herrscht, möchte ich Methoden die zu Lasten des Traffics und der Performance gehen eigentlich verhindern.

Tja, irgendwas muss ich mir wohl dann doch noch einfallen lassen um die Klassen zumindest teilweise zu verschlüsseln um das decompilieren bzw. das einsehen der Klasse schwerer zu machen.
Allerdings würde das decompilieren der dafür benötigten Klassen den dafür verwendeten Algorhytmus liefern, womit ich mir die Mühe auch wieder sparen könnte.

hm, vielleicht sollte ich einfach auf die moralische Korrektheit aller Anwender hoffen *lol*

Gruß Sparrow

 

[AlArenal]

Das Problem liegt meist nicht in der "Unsicherheit" von Javan-Anwendungen. Das Problem ist in der Regel, dass man nicht direkt auf den Port der DB zugreifen kann nd damit ist dann auch kein JDBC möglich.

Das kann z.B: in folgenden Szenarien der Fall sein:

1. Ich habe irgendwo Webspace mit einer DB, aber der Hoster erlaubt aus Sicherheitsgründen keinen externen DB-Zugriff (das sind i.d.R. alle Hoster).

2. Aus Sicherheitsgründen will ich nicht, dass der DB-Port meines Servers öffentlich oder im LAN zugänglich ist. Das betrifft Leute, die nen dedicated Webserver haben ebenso wie Firmen, zu deren Security Policies es gehört ihre Server in einer gut gesicherten DMZ zu betreiben (das sind i.d.R. alle größeren Firmen).

Aus privatem Umfeld kennen die meisten Punkt 1, aus beruflichen Gründen kenne ich viele Beispiele für 2. Es ist immer ganz was anderes lokal Anwendungen zu schreiben. Daheim und mit meinem Webserver kann ich machen was ich will, aber andernorts gibts ganz andere Rahmenbedingungen.

Im Übrigen kann ich auch den JDBC-Client wieder in Java umwandeln und schon kenne ich die DB-Struktur und möglicherweise gar die Zugangsdaten.

Ansonsten geht Sicherheit immer über Performance. Ansonsten muss ich sagen, dass für unsere Anwendungen die Performance über XML-RPC völlig okay ist. Wir haben zwar Anwendungen, die beim Start in einem Rutsch sehr viele Daten einlesen, aber da ist der Bottleneck nicht der Client, sondern der Server, weil PHP hier so lange braucht die Daten aus der DB zu holen und in XML-RPC zu verpacken. Es ist aber immer einfacher den Server zu tunen (PHP-Cache, bessere Hardware), als jeden Client aufrüsten zu lassen

 

[AlArenal]

P.S.:
Bei nem Applet das JDBC nutzt, komme ich doch immer an die DB-Zugangsdaten. Entweder durch Reverse Engineering des Bytecode (wenn ich die Daten fest im Code habe) oder über die Applet-Parameter (irgendwie muss ich die Zugangsdaten ja ins Applet bekommen).

Da haste dann Recht, egal wie ich verschlüssle, durch Dekompilierung komme ich immer irgendwie ran.

 

[Bleiglanz]

Warum XML-RPC und nicht SOAP?? Was solln das bringen, SOAP ist doch nichts anderes + etwas mehr? Oder ist das nur eine Sprachverwirrung?

Und warum nicht gleich Java-RMI, wenn Client und Server unter Java laufen (die Serialisierung in TEXT ist immer langsamer...)?

Solide Lösung für das Problem "Applet mit Zugriff auf DB" wäre z.B. ein Applicationserver (also gleich Middleware einsetzen, genau dafür wurde die ja erfunden),

Ohne Zwischenschicht kriegst du das aber in keiner Sprache gebacken, weil beim Direktzugriff der Client eben seine "Zugangsdaten" kennen muss...

Selbst wenn man das im Client-Binary verschlüsselt, dann kommen Netzwerk-Sniffer, die ein Passwort aus dem TCP/IP Verkehr rauslesen könnten, man müsste also über SSL auf die DB zugreifen, was nochmal Overhead verursacht...

 

[AlArenal]

Ich habe immer XML-RPC und SOAP genannt. Ich persönlich nutze ersteres, letzteres ist eher was für Webservices. Für RMI brauchts auch nen eigenen Port. Da wirst du auch bei Verwendung in größeren Unternehmen Probleme bekommen, denn eher wird Hitler heilig gesprochen, als dass da mal einer für eine kleine ANwendung nen Port in die Security Policies aufnimmt und in den Firewalls freischalten lässt

Was man evtl. machen könnte (braucht aber auch nen eigenen Port) ist das Tunneln über SSH. Ich weiß aber nicht ob das mit JDBC machbar ist. Ändert auch wenig an der Problematik mit der Ablage/Übergabe der Zugangsdaten. Das ist dann wie fette Alamranlage in den Wagen einbauen, aber Tür offen und Schlüssel stecken lassen.

 

[Bleiglanz]

FULL ACK, so einfach ist das alles nicht - manches geht halt nur im "internen" Netz

Meine Erfahrung ist eher, dass Hitler schon 100 Jahre heilig gesprochen ist, bevor man einem durchschnittlichen Admin erklärt hat, was man mit dem offenen Port machen will, was RPC überhaupt ist und warum das sinnvoll sein könnte

Die meisten sind so überlastet, da wird erstmal ALLES abgeblockt. Verkauft sich ja immer gut "wegen der Sicherheit"! Ich habe mal einen getroffen, der keinen Webserver fürs Intranet (!) einrichten wollte...

aber BTW: was ist der Unterschied zwischen ersterem und letzerem? Was genau verstehst du unter XML-RPC, wenn du damit NICHT meinst, dass du SOAP verwendest?

SOAP ist - zumindest der RPC Teil davon - doch nichts anderes als eine "moderne" XML-RPC Spezifikation??

 

[AlArenal]

Ist das so? Ich denke bei SOAP immer gleich an WSDL und Schnittstellen zu Amazon & Co.

Im Grunde tun sich beide nichts, ich empfand seinerzeit (als ich mich für XML-RPC entschied) dass die SOAP.Libs etwas aufwändiger zu bedienen waren. Vielleicht muss ichs mir nochmal genauer ansehen?

Admins sind schon ein komisches Volk. Mitunter bkommen wir keine Aufträge von Neukunden, obowhl deren Vorstand alles abgesegnet hat. Es stellt sich dann raus, dass sich die IT sperrt und meint, sie hätte das letzte Wort.

 

[Bleiglanz]

XML-RPC ist als Begriff ziemlich komisch, ich denke dabei immer an den/die vorläufer von soap

(es gab da mal verschiedene implementierungen für java)

besorg dir mal das JWSDP, die SOAP unterstützung ist mittlerweile ziemlich ausgereift, das ganze nennt sich dann

JavaTM API for XML-based RPC (JAX-RPC) 1.1.2 FCS