Mailinglist Archive: opensuse-programming-de (182 mails)

< Previous Next >
Re: Mysql und JDBC Grundsätze
  • From: Bodo Kaelberer <BodoKaelberer@xxxxxxxxxx>
  • Date: Wed, 17 Mar 2004 16:02:17 +0100
  • Message-id: <8712935821.20040317160217@xxxxxxxxxx>
Hallo

Ich weiss nicht, wieso diese Liste so konfiguriert ist, dass man
standardmaessig nur dem Autor und nicht der Liste schreibt. Da es
vielleicht andere auch interessant, poste ich nun meine Mail an Andre
noch mal an die Liste.

Hallo Andre.


>> > Das GUI soll "multiuser fähig" werden, nun denken ich das es
>> > ein kleiner Performanzgewinn sein könnte, wenn der Client keine
>> > Rechenoperationen mehr machen muss.
>>
>> Reden wir hier von 1 bis 5 Users oder von 1000? (-;

> Ich denke so bis 50 ist realistisch?? Habe ich mir ehrlich gesagt
> noch nicht genau überlegt!

> Je mehr je besser :)

> Was ist den bei vielen Usern besser, die Last auf den Server oder im
> Client?

Pauchal unbedingt der Client. Alles, was der Client tut, entlastet
erst mal den Server. Zu bedenken ist dabei aber der Aufwand, der fuer
den Server anfaellt, um dem Client die Daten zur Verfuegung zu
stellen. Nimmt das ueberhand, dann belastet es auch den Server
entsprechend. Und der Benutzer freut sich an nicht, wenn das System
staendig Daten hin und herschieb und er entsprechend warten muss.

Und dann natuerlich das Thema mit der Aktualitaet der Daten. Die sind
bei multi-user auf dem Server immer aktueller als im Client.

Da brauchst Du einfach ein Haendchen und eine Portion Erfahrung. Und
am meisten Erfahrung bekommst Du, wenn Du versuchst, solche Fragen
selbst zu klaeren. Wenn Du nicht weisst, ob A schneller ist oder B,
dann probier beides mal aus und miss die Zeit.


>> Was bietet JDBC an Sicherheitsmechanismen für die Übertragung,
>> z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer
>> verhindert, dass ein manipulierter Client ein "DROP TABLE
>> kundendaten" schickt?

> Gute Frage, per default wird alles in Klartext sein... (???)

Wenn JDBC fuer den Client-Server Einsatz gedacht ist, muss es da
irgendwelche Sicherheitsmechanismen gehen. Sonst kommst Du ja in
Teufels Kueche bzw. eigentlich kommst Du gar nirgends hin.


>> Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja
>> wohl kaum im Applet stehen. Oder doch?

> Es wird kein Applet geben. Auf dem Internetserver wird nur Apache
> mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt
> ist manipulierbar, z.B. in den jemand versucht die Servlets zu
> steuern.

Ach so. Also ein schlichtes Browser-Backend/Frontend? Da habe ich das
Client-Server-Thema ueberbewertet.


> Das UI muss ich mit Swing machen (leider gibt's QT nur als eval für
> M$) und ist zum Artikel rein hacken in eine "lokale DB" gedacht.

Also doch ein Applet fuer das Backend?


> Der Abgleich mit der DB auf dem I-Server wollte ich mittels SSH und
> XML lösen, vielleicht auch mit sql.txt. Das würde mit putty bzw pscp
> auf M$ ganz gut klappen. Mit Java gibt es allerdings auch eine API,
> womit man RSA & Co. benutzen kann.

Allgemein ist es sicherer, wenn der Client keinen direkten Zugriff auf
die Datenbank hat. Also am besten Servlets aufrufen und denen sagen,
was zu tun ist. Und dabei keine SQL-Statements verwenden, sondern
Parameter uebergeben. Die sind leichter zu ueberpruefen.

Und immer im Hinterkopf behalten: Java-Klassen koennen dekompiliert
werden. Also auf keinen Fall Passwoerter oder aehnlich sensible Daten
hartcodiert in Javacode, der beim Benutzer laeuft und somit den Server
verlaesst. Und wenn solche Daten uebers Internet nachgeladen werden,
ist wiederum zu bedenken, dass der Bytecode dekompiliert werden kann.
Es ist als moeglich, dass jemand den Code dekompiliert, sich abaendert
und sich dann Daten ausgeben laesst, die eigentlich niemand sehen
sollte.
Aber bei Open Source muss man ja nicht mal dekompilieren (-;

Es ist schon viel zu bedenken, wenn man sich bei serverseitigem CGI
keine Sicherheitsluecken einbauen will. Wenn dann noch ein Client
dazukommt, wird es noch schwieriger.

Und bei Shops geht's natuerlich auch um Geld. Hat man einen Bug in
einer Forum-Software, dann fehlen vielleicht mal ein paar Beitraege.
Aber wenn Kundendaten geklaut werden oder Daten von gelieferten und
noch nicht bezahlten Waren verloren gehen, dann ist der Aerger gross.

Da sollte man sich unbedingt mit gaengigen Sicherheitsmechanismen
vertraut machen. Und zwar nicht zu wissen, welche es gibt, sondern
auch wo ueblicherweise die Schwachstellen sind, an denen man sie
einsetzt.


Viel Spass (-;

--
1 Bodo Kaelberer
123 http://www.webkind.de/
3
4 Politik ist, wenn viele sich streiten und keiner sich freut.


< Previous Next >
Follow Ups