Zitat von
Elvis:
Zitat von
Errraddicator:
Und zu der ständigen Aussage "Weg von Client/Server Technolige, wir ham 2009 nich 1990, mach dies, tu das".
Wie soll ich das denn bei einer PHP-Anwendung machen?
Sogar PHP wird Remoting-Möglichkeiten wie
SOAP kennen. Falls du überhaupt einen Rich/Smart Client haben willst. Sieht mir eher nach einer Website aus.
Zitat:
Das ist doch prinzipbedingt eine C/S Anwendung, oder sehe ich das falsch?
Nö, nicht in dem Sinne, den ich meinte.
Ich bezog mich bei C/S darauf, dass dabei der User direkten Zugriff auf die
DB hat, und man deshalb so abartige Vergewaltigungen von RDMS-Features und Serverhardware braucht, um sich gegen diese Zugriffe des Users abzusichern.
Deine PHP Page wird ja selbst Zugangskontrolle ausüben, also warum denn das ganze NOCHMAL innerhalb der
DB machen?
Will heißen, du sorgst doch in dem PHP-Server schon dass User X nur Dinge sehen/machen darf, die er auch wirklich sehen/machen darf.
Warum willst du denn jetzt zusätzlich eine weitere Kontrolle einbauen, die dich dann immer und überall CPU-Zyklen, Speicher und vernünftige Querypläne kostet?
Richtig, es geht um eine Webseite.
Und falls es dem potenziellen Angreifer trotz div. Abfragen im PHP selbst, doch noch mal gelingen sollten den Schritt zur
SQL-Injection oder vergleichbarem gehen zu können, möchte ich halt auch auf
DB Seite so weit sein, dass er auch in dem Falle nicht in der Lage ist, eine komplette Benutzerliste z.B. auslesen zu können.
Das kann in meinem System (es sei denn ich habe was übersehen) nämlich keiner ausser dem Admin.
Deshalb ja auch dieser ganze Heck-Meck mit Views auf Views auf Tabellen und Co.
