|
|||
$var = $_POST['stuff'] ist immer leer, var_dump[$_POST] nicht
Hey, ich hab ein Problem bei der Übergabe von Daten mit POST.
Folgende Gegebenheiten: Mit var_dump sehe ich die übergebenen Daten. Exakt, wie sie sein sollten. Wenn ich dann aber die die Variablen aufrufe, in denen die Daten von dem POST Aufruf gespeichert werden sollten, sind diese leer. Wenn noch Fragen offen sind, beantworte ich die gern. Bis dahin schonmal danke! |
Sponsored Links |
|
|||
Kannst mal ein wenig Code zur Verfügung stellen, sonst weiss man ja gar nicht von was du sprichst.
Bitte rücke den Code entsprechend ein und verwende die PHP-Tags aus dem Edtitor zum Code einfügen.
__________________
"Wieso ist der Code schrott, ich dachte hier seien Profis..." Aus einem Forum. |
Sponsored Links |
|
|||
Ok! Ich hab's rausgefunden...
Mit $_Post gehts nich,... ABER mit $_POST! Wer hätte das gedacht? Danke trotzdem. PHP-Code:
Das ganze bekommt die 2 Variablen über eine Android app. Wie schon gesagt, seh ich mit var_dump den gesendet Inhalt und der stimmt auch. Nur sind $uMail und $uPW dann leer, wenn ich sie ausgebe oder sonstwas damit tue. Geändert von NicknameMk2 (21.08.2013 um 20:41 Uhr) |
|
|||
1. Es heistt $_POST und nicht $_Post
2. Du brauchst die Variablen nicht umzukopieren. du kannst das $_POST Array auch in der SQL-Abfrage verwenden. 3. In SQL Abfragen Schlüsselwörter gross schreiben, wegen der Übersichtlichkeit und auf mehrere Zeilen verteilen. 4. Gewöhne dir an lesbaren Code zu schreiben. 5. Parameter sollten man nicht ungeprüft übernehmen. Dein Code ist anfällig für SQL-Injections. 6. Dein Error-Reporting (E_ALL) solltest du einschalten, während der Entwicklungsphase 7. Aufgrund des Kontextwechsels kannst du PHP-Variablen nicht direkt in SQL-Abfragen nutzen: Das hier: PHP-Code:
Du musst die Stringverkettung anwenden. sauberer Code sieht so aus: PHP-Code:
__________________
"Wieso ist der Code schrott, ich dachte hier seien Profis..." Aus einem Forum. |
|
|||||
Hallo,
Zitat:
- Parameter aus $_POST/ $_GET extrahieren - Parameter auf Existenz prüfen - Parameter validieren - Parameter verarbeiten Zitat:
Zitat:
Zitat:
PHP-Code:
Zitat:
In meinen Augen sollte eine saubere und funktionsfähige Umsetzung der gesamten Problemstellung in etwa so aussehen: PHP-Code:
lotti
__________________
Empfehlenswerte Links: jsFiddle | JavaScript Patterns | RedBeanPHP | Mozilla Developer Network -/- W3C Validator | JSLint |
|
|||
In diesem fall wird die lesbarkeit eher nicht beintraechtigt, das ist an der stelle eher geschmackssache. Ich finde zum beispiel das man bei der direkten benutzung der post variable sofort erkennen kann worum es sich handelt, und das so lesbarer ist. Und das ganze erhoeht definitv nicht das sucherheits risiko, denn wenn man die variablen vorher prueft kommt es aufs selbe hinaus.
|
|
||||
Morgen,
Zitat:
Zitat:
- Variablen auf Existenz/ prüfen und extrahieren - Variablen validieren Wenn man diesen Ablauf befolgt kann man sich später relativ sicher sein, dass die Variable "$username" sauber ist. Bei einem $_POST['username'] im Code muss ich - wenn ich zwei Wochen später in den Code schaue - mir erstmal die Frage stellen: habe ich die auch validiert? Wie ein Entwickler die Dinge letztlich löst bleibt allerdings seine eigene Entscheidung. Wer vorsichtig ist, der kriegt's auch anders hin. Ich bevorzuge klare Strukturen im Code, da sich weitere Team-Mitglieder dann besser und schneller in meinem Code zurechtfinden. Viele Grüße, lotti
__________________
Empfehlenswerte Links: jsFiddle | JavaScript Patterns | RedBeanPHP | Mozilla Developer Network -/- W3C Validator | JSLint Geändert von lottikarotti (28.08.2013 um 11:00 Uhr) |
Sponsored Links |
|
|||
Um SQL-Injections zu verhindern sollte der Contextwechsel beachtet werden und mysql_real_escape_string() angewendet werden.
Weiteres dazu findet sich im Handbuch :>PHP: SQL Injection - Manual Das Umkopieren der übergebenen Variablen wird zwar oft gesehen, ist aber eigentlich nicht notwendig. Eine Variable bleibt eine Variable auch wenn sie durch umkopieren anders benannt wird. Es bleibt dem Programmierer überlassen ob er das macht oder nicht, es ging hier lediglich um die Notwendigkeit und die ist nicht gegeben. Das man SQL-Abfragen, auch wenn sie kurz sind, nicht in einer Zeile stehen lässt hat nichts mit der Übersichtlichkeit zu tun, sondern vielmehr damit, dass bei einem Fehler einem dann die Zeile angezeigt wird in der der Fehler auftrat. Je weniger man splittet, desto mehr muss man selber suchen. Prepared Statesment sind nicht der Weisheit letzter Schluss, sie können um einiges langsamer sein und vermeiden SQL-Injections nicht. In diesem gezeigten Fall, Abfrage der Useremail in Verbindung mit Passwort sind sie sogar kontraproduktiv, das sie das Caching des Abfragestrings auf Datenbankseite verhindern. Siehe dazu das Mysql-Handbuch.unter MySQL :: MySQL 5.1 Referenzhandbuch :: 5.14 MySQL-Anfragen-Cache
__________________
"Wieso ist der Code schrott, ich dachte hier seien Profis..." Aus einem Forum. |
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Nach 'Zurück'-Ereignis ist Formular leer | Kaimane | (X)HTML | 1 | 18.01.2008 09:29 |