$_POST Variablen-Type checken

[Forumsgast]

Hier steht geschrieben, dass es keinen Standard bei den Values von $_POST Variablen bezüglich der Variablen-Typen gibt.
https://www.php.net/manual/de/langua...mining-type-of

Bei mir werden Zahlen mit $_POST gesendet. Diese kommen aktuell als String rein. Die Values muss ich bei Eingang checken. Also muss ich erstmal checken ob es ein String oder Integer ist und den String mit intval() in einen Integer umwandeln. Vorher müsste ich checken, ob die Variable leer "" ist, weil ansonsten intval() aus "" = 0 macht, und 0 wäre ein Wert, der nicht gesendet wurde. Es müsste wohl eine if (is_numeric()) vorgeschaltet werden? Also irgendwie ist das wohl ein bisschen komplex?

Wie macht ihr das so mit Values aus $_POST?

[Forumsgast]

Prinzipiell sollte immer geprüft werden, ob valide Eingabewerte kommen.

Davon abgesehen, so wie du gesagt hast: Wenns ein leerer String ist, dann ist der Wert leer, ansonsten wird er in eine Zahl konvertiert.

is_numeric() ist übrigens mit Vorsicht zu genießen. Es kommt halt immer darauf an, was man erreichen will. Denn ein is_numeric("0xAFFE") liefert auch TRUE.

[Forumsgast]

Ja hellbringer, du bist ja hier ein Schnellposter. is_numeric("0xAFFE") liefert bei mir FALSE. und nu?

[Forumsgast]

Ja hellbringer, du bist ja hier ein Schnellposter. is_numeric("0xAFFE") liefert bei mir FALSE. und nu?

OK, hat sich wohl seit PHP 7 geändert, war bei PHP 5 anders. Noch gefährlicher, wenn sich das Verhalten von Funktionen von Version zu Version plötzlich ändert. Also ich würde is_numeric() nicht blind vertrauen.

Anderes Beispiel:

$value = "1e100";

var_dump(is_numeric($value));
// bool(true)

var_dump((int)$value);
// int(9223372036854775807) 

(diesmal in PHP 7 getestet )

"1e100" ist zwar eine valide Zahl, aber keine valide Ganzzahl.

[Forumsgast]

Wie macht ihr das so mit Values aus $_POST?

Mit ctype_digit()

[Forumsgast]

Mit ctype_digit()

? Das benötigt vorher einen check ob es ein String ist, und darum geht es hier gerade, dass $_POST nicht sicher auch immer einen String liefert. Es wäre wohl möglich, dass ein gesendeter Integer auch als Integer ankommt.

[Forumsgast]

? Das benötigt vorher einen check ob es ein String ist, und darum geht es hier gerade, dass $_POST nicht sicher auch immer einen String liefert. Es wäre wohl möglich, dass ein gesendeter Integer auch als Integer ankommt.

Nein, in einem $_POST-Wert steht nie ein Integer. Entweder ein String oder ein Array.

[Forumsgast]

Grundsätzlich sollten sowohl GET als auch POST sehr genau überprüft werden.
Erzeuge ein Array mit dem erwarteten Variablenamen und den erwarteten Typen
$expected:get=array("type"=>"int","name"=>"alpha" ,... );
Diese Tabelle und den GET übergibt du an deine Checkroutine (evtl eine CLASS).
In der Checkroutine arbeitest du den GET ab

1. Du weißt ob dein Programm überhaupt GET oder POST bekommen soll.
   

        // Wenn keine GET-Parameter vorhanden sind, kann eine weitere Prüfung entfallen  
         if(count($_GET) == 0) return; 

2. Angenommem du erwartest kein GET dann :
   

               if(count($GET) > 0 ) {         die("GET NOT allowed"); } 

3. jetzt kommt die Schwerarbeit Für jede Prüfungsart ist eine Function oder Methode zu schreiben
   die z.B per switch angesteuert wird
   
   

         foreach($_GET as $key => $val) {
           /* Wenn $key nicht in deiner Tabelle $expected_get ist,
       versucht jemand dir eine Variable unterzujubeln
         Mittels Regex und     Mittels regex und Filter  n
       https://www.php.net/manual/de/filter.filters.validate.php)  , ...
       jetzt die prüfen ob $val dem von dir festgelegten,
       erwarteteten Typ entspricht.
       Wenn ja kopiert du den Wert in eine Rückgabetabelle
         Nein , Fehlerflag setzen  Fehlermeldungen sammeln,
       für Auflistung aller Fehler am Ende.
       Eine Verarbeitung darf nicht stattfinden
       */
         }  // end foreach
        //   GET löschen und Fehlerflag auswerten und
       //   Rückgabetabelle verarbeiten
            /* Das muß du selbst programmieren.
             Diese Routinen schreibst du eimal richtig und gibst sie nicht weiter.
          */ 

   Die Routine (CLASS) ist analog auch für den POST zu machen
   
   // Seit Mitte Oktober 2018 wird bei allen ausgehenden Links in Facebook der fbclid Parameter angehängt.
   // Der von Facebook automatisch angehängte Parameter fbclid ähnelt dem
   // Google Ads Parameter gclid (Google Click Identifier).
   // Die löscht du einfach weg
   if(isset($_GET['fbclid'])){ unset($_GET['fbclid']); $_GET=array_values($_GET); }
   
   Wenn du dir diese CLASS geschrieben hast, kannst / mußt die sie in jedem Programm einsetzen, auch in php das per AJAX aufgerufen wird.
   Gehe davon aus daß das länger als einen Tag dauert .
   
   Viel Spaß
   
   papalangi_44

Nachtrag
Wie Hellbringer im vorherigen Beitrag geschrieben hat, kommen die Date als string an.
Das Wissen hatte ich vorausgesetzt, er war nur schneller.
Deshalb die Prüfungen mit regex und filter

[Forumsgast]

// Seit Mitte Oktober 2018 wird bei allen ausgehenden Links in Facebook der fbclid Parameter angehängt. […]
// Die löscht du einfach weg
if(isset($_GET['fbclid'])){ unset($_GET['fbclid']); $_GET=array_values($_GET); }

Mal abgesehen davon dass du dir mit array_values die Keys in $_GET kaputt machst: warum? Was stört an $_GET['fbclid']? Wenn da in $_GET mehr drinsteht ist das doch egal: wenn man da nicht darauf zugreift kann da drinstehen was will, das tut niemandem weh …

[Forumsgast]

Nein, in einem $_POST-Wert steht nie ein Integer. Entweder ein String oder ein Array.

Ach hellbringer, du wirst alt, oder es ist spät. Das was du da von dir gibst habe ich eingangs verlinkt. Es ist eben "nicht sicher".

@papalangi_44: die Idee mit den "erwarteten Typen" hat mich erstmal fasziniert, aber wen sollte dies abhalten das GET dementsprechend zu manipulieren? Es ist zudem für eine private interne Sache. Schon Internet, aber nichts öffentliches. Ich POSTe einen Integer und es kommt ein String. Vielleicht liegt das auch daran, dass der Integer noch nie ein Integer war oder beim POST zu einem String gemacht wurde: input value="123"? Und dann schreibt PHP, dass es eh "nicht sicher" ist, ob es jedesmal und in Zukunft ein Integer oder String sein wird, falls es ganz sicher ein Integer oder String war.

Was stört an $_GET['fbclid']? Wenn da in $_GET mehr drinsteht ist das doch egal: wenn man da nicht darauf zugreift kann da drinstehen was will, das tut niemandem weh …

ähm, ja, und das auch noch, also seh ich auch so.

[Forumsgast]

Ach hellbringer, du wirst alt, oder es ist spät. Das was du da von dir gibst habe ich eingangs verlinkt. Es ist eben "nicht sicher".

Was heißt "nicht sicher"?

Ich POSTe einen Integer und es kommt ein String. Vielleicht liegt das auch daran, dass der Integer noch nie ein Integer war oder beim POST zu einem String gemacht wurde: input value="123"? Und dann schreibt PHP, dass es eh "nicht sicher" ist, ob es jedesmal und in Zukunft ein Integer oder String sein wird, falls es ganz sicher ein Integer oder String war.

Befasse dich mal mit den HTTP-Grundlagen und wie ein HTML-Formular in der Regel von Browser übertragen wird.

Und zwar wird hierfür eine URL-kodierung, genauer gesagt eine Key-Value-Pair-Kodierung verwendet. Das ist am Ende dann nur ein langer String, da gibt es keine Datentypen wie Integer, Float oder sonst was.

Zum Beispiel ein Formular mit zwei Input-Feldern foo und bar wird so übertragen:

foo=1&bar=2

Dabei spielt es keine Rolle, ob die Ursprungswerte Strings oder Integer waren, sie werden auf die gleiche Weise kodiert mit dem selben Ergebnis.

Also foo: "1", bar: "2" ergibt genauso wie foo: 1, bar: 2 den kodierten String foo=1&bar2.

PHP bekommt diesen String, zerlegt ihn und schreibt anschließend die Werte $_POST['foo'] = '1' und $_POST['bar'] = '2'. Für PHP sind die Werte immer Strings, weil es keine Unterscheidungsmöglichkeit gibt.

Die einzige Ausnahme sind Keys, die [] enthalten. Die werden als Array zusammengefasst, wobei das mehr oder weniger auch nur eine Eigenheit von PHP ist und kein allgemeingültiges Gesetz.

Also foo[]=1&foo[]=2 ergibt $_POST['foo'] = ['1', '2'].

[Forumsgast]

Ach hellbringer, du wirst alt, oder es ist spät. Das was du da von dir gibst habe ich eingangs verlinkt. Es ist eben "nicht sicher".

Das Handbuch spricht zwar auf der von dir verlinkten Seite nur von den "meisten, wenn nicht alle[n]" Inhalten die bei HTTP-Requests als String ankommen - sagt aber nirgends was die Ausnahmen sein sollen. Im Handbuch zur Funktion ctype_digit() steht außerdem dass auch numerische Formulareingaben als String geliefert werden.

Und dann schreibt PHP, dass es eh "nicht sicher" ist, ob es jedesmal und in Zukunft ein Integer oder String sein wird, falls es ganz sicher ein Integer oder String war.

Meinst du den ersten Absatz in dem von dir verlinkten Abschnitt? Der bezieht sich auf Variablen in PHP allgemein, nicht auf Werte in $_POST/$_GET, die werden erst im zweiten Absatz behandelt.

[Forumsgast]

@hellbringer: "Es ist spät" gilt natürlich auch für mich. Und wenn ich es nicht "sicher" wüßte, würde ich nicht fragen. Also entschuldigt meine Frage. Mit dieser URL/HTTP Erklärung wird es mir klar. Da hatte ich anderweitig schon mit zu tun (URL Query Kram). Also ist diesbezüglich ein $_POST nichts anderes als ein $_GET. Wäre ja möglich gewesen, dass $_POST diesbezüglich mehr drauf hat als $_GET.

@tk1234: Danke für den Hinweis. Wenn etwas missverstanden werden kann, dann bin ich dabei! Das passt dann aber nicht wirklich: "PHP will not try to convert values to a specific type." Schließlich converted es INPUTIDARRAY%5B%5D=45431&INPUTIDARRAY%5B%5D=45432& INPUTIDARRAY%5B%5D=45433 zu einem PHP type "array". Irgendwie gut zu wissen keine eckigen Klammern in ein HTML "name" attribute zu verwenden, wenn es denn kein Array werden soll, like name="dumm[di]dumm". Aber wer macht schon sowas... Irgendwo war das auch erklärt.

[Forumsgast]

Im Handbuch zur Funktion ctype_digit() steht außerdem dass auch numerische Formulareingaben als String geliefert werden.

Da stehts. nasowas. Wäre ja mal praktischer es würde auf der von mir verlinkten Seite stehen.
ctype_digit() wäre diesbezüglich dann ähnlich einem regex like [0-9] ? Ein Integer ist eh nicht dabei. Oder kann das noch mehr? ... und dann der Changelog. Da müsste man sich drauf verlassen, dass das so bleibt. Weil "" = true wäre doof.

[Forumsgast]

Wie macht ihr das so mit Values aus $_POST?

$options=array('options'=>array('default'=>null, 'min_range'=>1900, 'max_range'=>2020));
$year=filter_input(INPUT_GET, 'year', FILTER_VALIDATE_INT, $options);

var_dump($year); 

http://localhost/test/filter_input.php?year=a
ergibt den default Wert, hier null. wenn der Parameter nicht gesetzt ist oder ausserhalb des zulässigen Rahmens liegt, ansonsten den übergebenen Wert als integer.
Spart eine menge Überlegungen.