Folgende Situation dürfte ziemlich standard sein für Webanwendungen:
- die Anwendung erstellt eine Form, deren Inhalt durch einige Datenbankanfragen zusammengesetzt wird
- der User drückt submit
- die Anwendung macht irgendwas mit den Daten
Der letzte Punkt ist der kritische. Theoretisch könnte man alle Daten aus der Datenbankanfrage mit in dem $_POST übermitteln. Allerdings kann man den Daten dann nicht trauen. Alternativ kann man alle Datenbankanfragen neu machen -> blöd. Oder beim Druck auf submit die benötigten Daten in $_SESSION übermitteln.
Letzteres scheint mir die sinnvollste Lösung, jedoch hab ich keine Ahnung und dachte ich frag mal wie ihr es macht.
mfG,
Sören
$_POST Daten vertrauen...
gepostet vor 19 Jahre von BuschnicK
gepostet vor 19 Jahre von stephan_
Hi.
Also, wir ueberpreufen jeden Wert, bevor irgendwas in die DB kommt. D.h. wenn wir in dem Feld eine Zahl erwarten, dann darf dort nur eine Zahl drinnenstehen. Ansonsten wird alles verworfen.
Schwierig wirds bei einem Textfeld o.ae. Dort kannst du aber alle Sonderzeichen (zB <,>,|, $ etc) ersetzten. zB durch den HTML Code.
Erst wenn alle Variablen nur das beinhalten, was drin sein darf, wird es in die Datenbank geschrieben.
Was die Manipulation von $_POST angeht, wuerd ich sagen, es ist soweit ertraeglich. Fuer jedes Forumular eine eigene session ist schon sehr aufwaendig. Selbst das ganze immer in die $_SESSION Variable schreiben macht wenig sinn. Da schleifst du am Ende 100 oder mehr Sachen in der Session rum.
Lg
Stephan Breitrainer
ZIONnetworx
Also, wir ueberpreufen jeden Wert, bevor irgendwas in die DB kommt. D.h. wenn wir in dem Feld eine Zahl erwarten, dann darf dort nur eine Zahl drinnenstehen. Ansonsten wird alles verworfen.
Schwierig wirds bei einem Textfeld o.ae. Dort kannst du aber alle Sonderzeichen (zB <,>,|, $ etc) ersetzten. zB durch den HTML Code.
Erst wenn alle Variablen nur das beinhalten, was drin sein darf, wird es in die Datenbank geschrieben.
Was die Manipulation von $_POST angeht, wuerd ich sagen, es ist soweit ertraeglich. Fuer jedes Forumular eine eigene session ist schon sehr aufwaendig. Selbst das ganze immer in die $_SESSION Variable schreiben macht wenig sinn. Da schleifst du am Ende 100 oder mehr Sachen in der Session rum.
Lg
Stephan Breitrainer
ZIONnetworx
gepostet vor 19 Jahre von BuschnicK
Direkt User Eingaben überprüfen ist klar, das mach ich sowieso. Also Textbox nur erklaubte Zeichen/Länge, Zahlen nur Zahlen etc.
Was ich meinte war eher so etwas:
Ein Combobox zeigt eine Liste aller Gebäude an, die momentan gebaut werden können. Um dies herauszufinden gab es eine Datenbankabfrage, die die nötigen Bedingungen dazu überprüft.
submit form würde das Gebäude nun in Auftrag geben. Dazu müssen jetzt theoretisch alle Bedingungen noch einmal verifiziert werden, weil der User ja böse Daten einspeisen könnte.
Um diesen Fall der doppelten Datenbankabfrage für dieselben Informationen zu umgehen dachte ich, ich packe die Daten in die SESSION. Bei submit würde ich sie dann dort auslesen und anschliessend unset machen...
Gute Idee oder Holzweg?
mfG,
Sören
Was ich meinte war eher so etwas:
Ein Combobox zeigt eine Liste aller Gebäude an, die momentan gebaut werden können. Um dies herauszufinden gab es eine Datenbankabfrage, die die nötigen Bedingungen dazu überprüft.
submit form würde das Gebäude nun in Auftrag geben. Dazu müssen jetzt theoretisch alle Bedingungen noch einmal verifiziert werden, weil der User ja böse Daten einspeisen könnte.
Um diesen Fall der doppelten Datenbankabfrage für dieselben Informationen zu umgehen dachte ich, ich packe die Daten in die SESSION. Bei submit würde ich sie dann dort auslesen und anschliessend unset machen...
Gute Idee oder Holzweg?
mfG,
Sören
gepostet vor 19 Jahre von stephan_
Achso meinst du das..
wir haben da auch eine doppelte Abfrage drinnen, bzw. vergleichen die werte vorher mit den Eingaben.
Ich weiss nicht, ob das ganze mit $_SESSION so sinnvoll ist. Weil du ja irgendwann einen Haufen solcher Werte mitschleppst, und auch Sessions kann man hijacken
Lg
Stephan Breitrainer
ZIONnetworx
wir haben da auch eine doppelte Abfrage drinnen, bzw. vergleichen die werte vorher mit den Eingaben.
Ich weiss nicht, ob das ganze mit $_SESSION so sinnvoll ist. Weil du ja irgendwann einen Haufen solcher Werte mitschleppst, und auch Sessions kann man hijacken
Lg
Stephan Breitrainer
ZIONnetworx
gepostet vor 19 Jahre von Fornax
Und in der Zeit vom Seitenaufruf (sachen in die session schreiben) bis er dann baut (aus der session lesen), kann einiges passieren. Wenn er 5 Min. kurz weg ist, in der Zeit eine Forschung fertig wird, o.ä. sind die Daten schon wieder unbrauchbar
gepostet vor 19 Jahre von Kampfhoernchen
Ich bin mir jetzt net ganz sicher, wozu das gut sein soll.
Daten übermittele ich nur an den Client, wenn der sie braucht. Wenn ich die am Server schon vorrätig hab (sprich in der Datenbank, Session), nehm ich die vorhandenen, weil alles was von außen kommt is potzenzielle Angriffsfläche und kann missbraucht werden (zum Beispiel von Bot ect).
Daten übermittele ich nur an den Client, wenn der sie braucht. Wenn ich die am Server schon vorrätig hab (sprich in der Datenbank, Session), nehm ich die vorhandenen, weil alles was von außen kommt is potzenzielle Angriffsfläche und kann missbraucht werden (zum Beispiel von Bot ect).
gepostet vor 19 Jahre von BuschnicK
War nur einer Idee um die doppelten Datenbankabfragen für dieselben Informationen zu sparen.
Ihr habt mich aber davon überzeugt, dass das nicht der richtige Weg ist ;-)
mfG,
Sören
Ihr habt mich aber davon überzeugt, dass das nicht der richtige Weg ist ;-)
mfG,
Sören
gepostet vor 19 Jahre von Chojin
Es ist absolut sinnlos sowas in der Session zu speichern weil die performance die durch das session handling draufgeht genausogut in eine kleine datenbankabfrage investiert werden kann. :roll:
Obendrein is das zweite datenbankquery ja vergleichsweise kleiner, da man nur auf die übergebene ID prüfen muss ob sie "Machbar" ist und nicht nochmal alle Objekte durchchecken muss.
Mir fällt grade ein das du das Update (das du ja eh machen musst um den vorgang in gang zu setzen) mit der überprüfung der variabeln im query verbindest
reg4rds
chojin
Obendrein is das zweite datenbankquery ja vergleichsweise kleiner, da man nur auf die übergebene ID prüfen muss ob sie "Machbar" ist und nicht nochmal alle Objekte durchchecken muss.
Mir fällt grade ein das du das Update (das du ja eh machen musst um den vorgang in gang zu setzen) mit der überprüfung der variabeln im query verbindest
reg4rds
chojin
gepostet vor 19 Jahre von Kallisti
Username, ID, Koordinaten, Grafikpackurl und maybe paar bool werte (hilfefunktion an / aus..) in die Session.
Sonst nix.
jeglichen Daten die vom Client kommen darf man NIEMALS vertrauen.
Sonst nix.
jeglichen Daten die vom Client kommen darf man NIEMALS vertrauen.
gepostet vor 19 Jahre von Chojin
Die session daten liegen aber im arbeitspeicher und auf der festplatte vom server :roll:
Der rest stimmt.
Der rest stimmt.
gepostet vor 19 Jahre von schokofreak
Original von BuschnicK
Ein Combobox zeigt eine Liste aller Gebäude an, die momentan gebaut werden können. Um dies herauszufinden gab es eine Datenbankabfrage, die die nötigen Bedingungen dazu überprüft.
Holzweg. Wenn du die Datenbank sauber designet hast, so ist es gar nicht möglich, ein Gebäude / einen Bauauftrag zu speichern, wenn man das noch nicht tun dürfte.
Solche Probleme liegen zwingend daran, dass du das Datenbankdesign nicht sauber durchgeführt hast.
Sprich anstatt hier immer wieder Checks durchzuführen, bekämpf die Ursache und ned deren Auswirkungen.
Gruss
gepostet vor 19 Jahre von KoMtuR
Original von schokofreak
Original von BuschnicK
Ein Combobox zeigt eine Liste aller Gebäude an, die momentan gebaut werden können. Um dies herauszufinden gab es eine Datenbankabfrage, die die nötigen Bedingungen dazu überprüft.
Holzweg. Wenn du die Datenbank sauber designet hast, so ist es gar nicht möglich, ein Gebäude / einen Bauauftrag zu speichern, wenn man das noch nicht tun dürfte.
Solche Probleme liegen zwingend daran, dass du das Datenbankdesign nicht sauber durchgeführt hast.
Sprich anstatt hier immer wieder Checks durchzuführen, bekämpf die Ursache und ned deren Auswirkungen.
Gruss
Gleich mal ne Frage zu deiner Antwort wegen Datenbankdesign. Ist es empfehlenswert InnoDB zu nehmen bei Browsergames oder eher MyIsam. Mit inno könnte man ja solche Fehleinträge vermeiden und Transaktionen nutzen. Ich weiß aber nicht, wie sich so die Speed bei großen Projekten auswirkt
gepostet vor 19 Jahre von schokofreak
Meiner Meinung sollte man, wenn man HEUTE anfängt und somit entscheidet, auf MySQL 5.0 setzen - wodurch sich so ziemlich alles ändert.
Frag mich jetzt nur nicht, wie sauber MySQL 5.0 funktioniert... oder wies skaliert. Geschweige denn was man dort so für Tabellen hat ;-)
InnoDB ist MyISAM (zumindest under MySQL 4) sicher vorzuziehen. Negative Faktoren bei grossen Tabellen hab ich noch nie gesehen (allerdings auch noch nie mit wirklich grossen Tabellen gearbeitet). Innodb ist leider einfach nicht sooo verlässlich was die Transaktionen angeht, aber da lässt sich halt ned viel machen.
Und irgendwie denke ich, dass das DB Design nur sekundär vom Tabellentyp abhängig ist
Gruss
Frag mich jetzt nur nicht, wie sauber MySQL 5.0 funktioniert... oder wies skaliert. Geschweige denn was man dort so für Tabellen hat ;-)
InnoDB ist MyISAM (zumindest under MySQL 4) sicher vorzuziehen. Negative Faktoren bei grossen Tabellen hab ich noch nie gesehen (allerdings auch noch nie mit wirklich grossen Tabellen gearbeitet). Innodb ist leider einfach nicht sooo verlässlich was die Transaktionen angeht, aber da lässt sich halt ned viel machen.
Und irgendwie denke ich, dass das DB Design nur sekundär vom Tabellentyp abhängig ist
Gruss
gepostet vor 19 Jahre von Kallisti
Original von schokofreak
Holzweg. Wenn du die Datenbank sauber designet hast, so ist es gar nicht möglich, ein Gebäude / einen Bauauftrag zu speichern, wenn man das noch nicht tun dürfte.
[...]
bezweilfe ich.. ich denke, dass es durchaus sinnvolle und saubere Datenbankdesigns gibtm, die eine Ueberpruefung dennoch noetig machen. Dafuer haben diese Designs groesse Vorteile an anderer Stelle.
gepostet vor 19 Jahre von Derpendja
Original von schokofreak
Holzweg. Wenn du die Datenbank sauber designet hast, so ist es gar nicht möglich, ein Gebäude / einen Bauauftrag zu speichern, wenn man das noch nicht tun dürfte.
Solche Probleme liegen zwingend daran, dass du das Datenbankdesign nicht sauber durchgeführt hast.
Sprich anstatt hier immer wieder Checks durchzuführen, bekämpf die Ursache und ned deren Auswirkungen.
Gruss
Mag ja sein, dass unmögliche Gebäude nicht in der Liste erscheinen, aber irgendwie musst du die gewählte Auswahl ja wieder übergeben (wahrscheinlich die ID des Gebäudetyps als hidden) - und die kann man manipulieren, in dem man z.B. ausprobiert was passiert, wenn man eine ID angibt, die nicht übergeben werden kann. Mit ein wenig probieren und Geduld kann man so alle Gebäude-IDs ermitteln. Es muss also nicht am DB-Design liegen, eine Prüfung der übergebenen Parameter ist dennoch immer notwendig (auch wenn da eigentlich unmögliche Werte übergeben werden).
gepostet vor 19 Jahre von Thomblin
Hab das hier mal verfolgt
und nun mal eine Frage an schokofreak:
wie hast du denn deine datenbank designed, dass keine zb falschen gebäude in die DB gelangen können, ohne abfrage?
bei mir zb hat jedes gebäude nen nummer und die wird gespeichert. da würde mir sowas jetzt nicht einfallen ... klär mich bitte auf
und nun mal eine Frage an schokofreak:
wie hast du denn deine datenbank designed, dass keine zb falschen gebäude in die DB gelangen können, ohne abfrage?
bei mir zb hat jedes gebäude nen nummer und die wird gespeichert. da würde mir sowas jetzt nicht einfallen ... klär mich bitte auf
gepostet vor 19 Jahre von Tweety
Naja, so pauschal kann man das bestimmt nicht sagen - das kommt auf das Spiel an, und auf die Komplexität der Bedingungen, die gegeben sein müssen, um was zu bauen. Wenn beispielsweise Gebäude nur abhängig von einem einzigen Zahlenwert (Stufe, Geld, eine bestimmte Forschung, was weiß ich) freigegeben werden, dann geht das durchaus auch mit einer einzigen Datenbankabfrage. Wenn da aber noch andere Faktoren reinspielen, dann wird die Abfrage (wenn sie dann überhaupt machbar ist) sehr, sehr lang und muss dementsprechend oft joinen oder ähnliche speicheraufwendige Dinge tun, um das gewünschte Ergebnis zu erhalten.