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

< Previous Next >
Re: Mysql und JDBC Grundsätze
  • From: Andre Heine <linux-experience@xxxxxxx>
  • Date: Wed, 17 Mar 2004 20:24:50 +0100
  • Message-id: <200403172024.50860.linux-experience@xxxxxxx>
Am Mittwoch, 17. März 2004 16:02 schrieb Bodo Kaelberer:
> 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.

IMHO ist Deine Mail korrekt in der Liste angekommen,
mir ist jedenfall nichts aufgefallen...

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

[...]

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

Hmm, meine Meinung geht jetzt dahin, alle Berechnungen im Client
zumachen.

> Und dann natuerlich das Thema mit der Aktualitaet der Daten. Die
> sind bei multi-user auf dem Server immer aktueller als im Client.
> >> 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?

Nein ...
Soll ein Backend für den Desktop werden, läuft in keinem Browser.

SWT werde das zu mal probieren ...

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

Wie wahr, wie wahr, wie wahr ...

> Viel Spass (-;

Und viel Arbeit ;)


Ciao

Andre

< Previous Next >