nicht angemeldet
Hallo Martin,
jaja, aber die Philosopie, gerade auch bei sprinf, ist ja die, dass der Platzhalter den ursprünglichen Typ des Parameters angeben soll. Dass er hinterher Teil eines Strings wird, ist klar. Aber deswegen habe ich angedeutet, dass es PHP und Javascript mit den Datentypen eh nicht so eng sehen.
Beim sprintf() von PHP gibt es ja gar kein %i. Könntest du mir sagen, welcher von den Specifiers einem „normalen“ Integer gleichkommt?
Das ist in C ganz anders: Wenn da im Formatstring für sprintf() ein %s steht, dann interpretiert die Funktion den übergebenen Parameter auch mit aller Gewalt als Zeiger auf eine Zeichenkette. Wenn dann beispielsweise der Zahlenwert 8 übergeben wird, will sprintf() auf eine Zeichenkette ab Adresse 0x00000008 im Arbeitsspeicher der Anwendung zugreifen. Das ist dann eventuell ein nicht erlaubter Zugriff, und die Anwendung fliegt mit Memory Access Violation achtkantig raus.
Nun, bin leider kein Fachmann. Aber interessant zu wissen ist es schon. Womöglich komme ich ja mal in andere Gefilde als Web-Programmierung. Neben meinem richtigen Beruf und zwei kleinen Kindern reicht die Zeit leider immer nur bedingt für das Hobby. Es gibt aber viel zu wissen.
Ja, aber sollte die JSON-Datei nicht urprünglich auch die Limits selbst enthalten? - Egal, ich wollte nur nochmal betonen, dass alles, was clientseitig abläuft, vom Nutzer manipulierbar und damit nicht vertrauenswürdig ist. Eine clientseitige Validierung von Eingaben ist nice to have, aber nach dem Absenden der Daten muss in jedem Fall noch eine serverseitige Validierung vor der Weiterverarbeitung erfolgen.
Wäre schön, vielleicht baue ich die Limits auch mal ein. Die ganze Validierungsgeschichte ist für meine Verhältnisse doch ein recht großes Konstrukt. Die JSON-Datei liegt halt im public-Ordner und der ist ja, wie der Name schon sagt, öffentlich. Deswegen meine Bedenken, da Limits zu speichern. Die serverseitige Validierung hatte ich als allererstes geschrieben. Sie greift ebenso wie die clientseitige Validierung auf diese JSON-Datei zu, in der sich die Formulierungen für die Fehlermeldungen befinden.
Bedenke auch, dass böse Buben vielleicht gar nicht dein Formular oder deine Web-App verwenden, um Daten an dein Script zu senden. Sondern Tools wie wget oder curl, mit denen sie sorgfältig handgestrickte Requests bauen können, die deine aufgestellten Regeln ganz gezielt verletzen.
Nun, kann ich mit PHP nicht überprüfen, ob der POST-Request vom Formular stammt oder von irgendwo anders? Es ist ein Abgrund mit den potenziellen Sicherheitslücken.
Grüße
Boris
Der Martin