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.