Toon posts:

$_GET beveiligen

Pagina: 1
Acties:

  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
Heeej,

Ik beveilig altijd mijn $_GET's zo:

code:
1
2
3
4
5
6
7
8
9
10
11
    if(is_numeric($_GET["id"])) {
        $id = $_GET["id"];
    } else {
        $id = "0";
    }
        
    if(is_numeric($_GET["g"])) {
        $g = $_GET["g"];
    } else {
        $g = "0";
    }


Zo weet ik zeker dat het een nummer is en dat ik hem veilig overal kan gebruiken, alleen mijn vraag is, kunnen ze niet uit de is_numeric() breken?
Ik denk van niet,
Ik kan wel vinden dat als je een gegevens van een user op je site wilt outputten dat je html_special_chars moet gebruiken, in een database mysql_real_escape_string als addslashes niet standaard aan staat. etc etc

  • Sebazzz
  • Registratie: september 2006
  • Laatst online: 18:51
Waarom gebruik je niet gewoon mysql_real_escape_string? Naar numeriek omvormen is meer symptoombestrijding. Overigens kan je hem ook casten naar een integer:
PHP:
1
$id = (int) $_GET["id"];

[Website en online portfolio] [Return: realtime retrospective tool] [PokerTime planning poker]


  • CyBeR
  • Registratie: september 2001
  • Niet online

CyBeR

💩

lauwsa schreef op donderdag 21 oktober 2010 @ 17:56:
Heeej,

Zo weet ik zeker dat het een nummer is en dat ik hem veilig overal kan gebruiken, alleen mijn vraag is, kunnen ze niet uit de is_numeric() breken?
Daarvoor moet je even kijken wat is_numeric() precies doet in de source van php. Vermoedelijk is 't een vrij simpel loopje waar weinig mee te klooien valt.

All my posts are provided as-is. They come with NO WARRANTY at all.


  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
owja dat kan hier ook, bedankt. Ik gebruik geen mysql_real_escape_string omdat het een getal moet zijn wat ik nodig heb, en casten had ik nog niet aan gedacht, bedankt :D

  • Icelus
  • Registratie: januari 2004
  • Niet online
Sebazzz schreef op donderdag 21 oktober 2010 @ 17:58:
Waarom gebruik je niet gewoon mysql_real_escape_string? Naar numeriek omvormen is meer symptoombestrijding. Overigens kan je hem ook casten naar een integer:
PHP:
1
$id = (int) $_GET["id"];
Gaat helaas mis bij iets als:
PHP:
1
$id = (int) "2a"; // $id = 2

Developer Accused Of Unreadable Code Refuses To Comment


  • Sebazzz
  • Registratie: september 2006
  • Laatst online: 18:51
Icelus schreef op donderdag 21 oktober 2010 @ 18:02:
[...]
Gaat helaas mis bij iets als:
PHP:
1
$id = (int) "2a"; // $id = 2
Dat lijkt mij prima gedrag.

[Website en online portfolio] [Return: realtime retrospective tool] [PokerTime planning poker]


  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
Als er niks uit komt is het toch gewoon niks, dus null. Dat maakt dan toch niks uit.
De get moet een getal zijn anders maak ik het zelf 0.

Maar ik ga het nu even uitproberen.
Het word dan 0, bedankt!
Dat is best wel een grote verkoring.

[Voor 15% gewijzigd door lauwsa op 21-10-2010 18:12]


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 17:20

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Sebazzz schreef op donderdag 21 oktober 2010 @ 18:08:
[...]

Dat lijkt mij prima gedrag.
Mij niet. "2a" is niet hetzelfde als "2". "a2" wordt toch ook geen 2?

[Voor 6% gewijzigd door .oisyn op 21-10-2010 18:18]

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • Cartman!
  • Registratie: april 2000
  • Niet online
Hoe veilig denk je dat het is? Vang je het nog af als iemand "1e4" doorgeeft? of "0xFF"? Die valideren gewoon op is_numeric maar ik gok erop dat dit niet is wat jij wilt. Pak dan eerder ctype_digit(), die checkt of een string (!) bestaat uit enkel getallen.

  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
Maar kan het dan veel kwaad als je 0xFF door geeft,
want hij kijkt oa als het in de db voor komt, maar dat breekt toch niet echt ergens uit.

Maar bedankt :D, dit is wel handig voor andere keren.

  • Sebazzz
  • Registratie: september 2006
  • Laatst online: 18:51
.oisyn schreef op donderdag 21 oktober 2010 @ 18:17:
[...]

Mij niet. "2a" is niet hetzelfde als "2". "a2" wordt toch ook geen 2?
Als het gewoon gedocumenteerd is, dan is het prima gedrag. Zo werkt het gewoon in PHP.

[Website en online portfolio] [Return: realtime retrospective tool] [PokerTime planning poker]


  • Osiris
  • Registratie: januari 2000
  • Niet online
Cartman! schreef op donderdag 21 oktober 2010 @ 18:49:
Hoe veilig denk je dat het is? Vang je het nog af als iemand "1e4" doorgeeft? of "0xFF"? Die valideren gewoon op is_numeric maar ik gok erop dat dit niet is wat jij wilt.
Waarom niet? Het is gewoon een andere manier van noteren.. (En derhalve "gewoon" een getal.) Het ligt er maar net aan wát ie er mee gaat doen hè en of de volgende stappen het ook als getal accepteren.

Dat 1e4 een nogal groot getal is wat mísschien buiten de gebruikte range valt is een compleet ander verhaal en afhankelijk van volgende restricties die de TS wellicht ingebouwd heeft.

MySQL pakt iig gewoon 0x0a als hexadecimale vorm van decimaal 10 in een query, dussuh.. :) En ook 1e4 als 10 000.

[Voor 7% gewijzigd door Osiris op 21-10-2010 20:12]


  • ray538
  • Registratie: januari 2010
  • Laatst online: 14:33
Als aanvulling op de besproken "1e4" en "0xFF": ook kommagetallen worden doorgelaten door is_numeric() (het is immers een numeriek getal). Het vormt in principe geen veiligheidsrisico (in de zin van SQL injection) om is_numeric te gebruiken, maar ik ben van mening dat je moet controleren op dat wat je verwacht. In veel gevallen gaat het om ID's in een database. Je verwacht dus een geheel numeriek getal en controleert dus ook of dat aanwezig is (en niet of een gebruiker een of andere andere notatie heeft gebruikt) met ctype_digit().

  • YopY
  • Registratie: september 2003
  • Laatst online: 16-09 14:48
Maar nu even terug. Het topic gaat over 'beveiligen' van de invoer van cijfers. Kan er dan ingebroken worden als je id=2e of id=0xff of id=1,337 doet? Of is het meer het voorkomen van fouten aan de gebruikerskant?

  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
http://nl3.php.net/is_numeric
'42' is numeric
'1337' is numeric
'1e4' is numeric
'not numeric' is NOT numeric
'Array' is NOT numeric
'9.1' is numeric
Ofwel wiskundige notaties mogen ook. Zoals al eerder gezegt in dit topic. Zoals ray538 zegt doet ctype_digit wat je wil.

Let wel op ctype_digit werkt alleen op strings, dus:
PHP:
1
2
ctype_digit(0); // Dit doet niet wat je verwacht
ctype_digit("0"); // Dit doet wel wat je verwacht, en _GET is altijd een string of een array.


Ik zie altijd graag of een array uit de url komt daarom pas ik de waarde in de _GET meestal gewoon aan:
PHP:
1
2
3
if ( !ctype_digit($_GET['a']) ) {
    $_GET['a'] = 0;
}

Maar dat is een kwestie van smaak.
(..) Het topic gaat over 'beveiligen' van de invoer van cijfers.(...)
SQL errors en ik heb me ooit laten vertellen dat MySQL het moeilijk kan hebben met extreem grote getallen, maar pin me daar niet aan vast.

Daarnaast is het naar mijn mening een (beveligings-)lek op het moment dat de gebruiker iets anders kan invoeren dan je verwacht. Je laat het gat in je muur ook niet zitten omdat het nog steeds niet koud is.

[Voor 23% gewijzigd door ReenL op 21-10-2010 20:38. Reden: Laatste quote toegevoegd]


  • FragFrog
  • Registratie: september 2001
  • Laatst online: 22:35
YopY schreef op donderdag 21 oktober 2010 @ 20:24:
Maar nu even terug. Het topic gaat over 'beveiligen' van de invoer van cijfers. Kan er dan ingebroken worden als je id=2e of id=0xff of id=1,337 doet? Of is het meer het voorkomen van fouten aan de gebruikerskant?
Als je database errors uitspuugt in plaats van netjes naar een errorlog schrijft? Ja, dat geeft een hacker informatie die hij niet had moeten hebben. PHP mag bepaalde strings dan zien als getal, dat betekent nog niet dat het ook goed gaat wanneer je ze gebruikt in een query die een int verwacht.

Casten naar een int is in mijn opinie de beste oplossing. Als een gebruiker dan bewust foutieve informatie erin stopt krijgt hij exact dezelfde info als wanneer hij het ID aanpast, en dat laatste kun je toch niet voorkomen. Het zal nooit exceptions opleveren of op een andere manier je code stukmaken. Bovendien is het korter en simpeler (dus minder foutgevoelig) dan een check op numeriek + else conditie. Stel dat je die "else $value = 0" een keer vergeet ga je vervolgens nog veel vagere errors krijgen, maar kom je daar niet achter tot je daadwerkelijk eens foutieve info gaat invoeren - en laten we eerlijk zijn, als je daar geen testers voor hebt wil er nog wel eens eentje doorheen slippen ;)

[Voor 19% gewijzigd door FragFrog op 21-10-2010 20:33]

[ Site ] [ twitch ]


  • frickY
  • Registratie: juli 2001
  • Laatst online: 21:03
Foute input is gewoon fout, ook als je er toch iets van zou kunnen maken.
Of voeg je ook 7 voorloop nullen toe als iemand 123 als telefoonnummer invoert?

Als iemand een ID moet geven dan moet je ook een ID eisen. Dan moet je niet de input zodanig gaan converteren tot je er een ID uit kunt herleiden.

@ReenL
Schrijven naar één van de superglobals is, met uitzondering van $_SESSION, ook geen goed idee.
Houd user-input en variabelen die je gevalideerd hebt gescheiden, zodat je altijd weet welke je kunt vertrouwen en welke niet.

[Voor 42% gewijzigd door frickY op 21-10-2010 20:33]


  • Gamebuster
  • Registratie: juli 2007
  • Laatst online: 17:35
PHP:
1
$a = (int)$_GET['a'];


Lijkt mij voldoende.

Wat de input ook was, er komt altijd een geldig numeriek getal uit. Bij vreemde input kunnen er misschien wat vreemde resultaten vormen, maar dit zal nooit een beveiligingsprobleem zijn voor je queries.

mysql_real_escape_string is dan ook niet nodig, aangezien $a geen "string" is.

Toch, misschien eens kijken naar PDO met Prepared Statement?

[Voor 72% gewijzigd door Gamebuster op 21-10-2010 20:35]

Let op: Mijn post bevat meningen, aannames of onwaarheden


  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
@frickY
Zoals ik al zei een kwestie van smaak. In mijn code kan je in een oogopslag zien welke variablen van de gebruiker komen en dus niet te vertrouwen zijn. Bij jou code moet je vertrouwen dat alle globals goed zijn omgezet naar non-globals.

@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.

  • Gamebuster
  • Registratie: juli 2007
  • Laatst online: 17:35
ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@frickY
Zoals ik al zei een kwestie van smaak. In mijn code kan je in een oogopslag zien welke variablen van de gebruiker komen en dus niet te vertrouwen zijn. Bij jou code moet je vertrouwen dat alle globals goed zijn omgezet naar non-globals.

@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.
Dan moet diegene geen typo maken / clientside controleren in Javascript / html SELECT-element gebruiken.

Text-input moet je naar mijn mening als tekst behandelen. Iemand een getal laten typen en als getal behandelen moet je vermijden naar mijn mening.

[Voor 12% gewijzigd door Gamebuster op 21-10-2010 20:42]

Let op: Mijn post bevat meningen, aannames of onwaarheden


  • Pendaco
  • Registratie: augustus 2003
  • Laatst online: 13:43

Pendaco

Vogon Poetry FTW!

Waarom niet gebruik maken van de filter vars, dan kun je iig nog een range opgeven?

PHP:
1
$id = filter_var($_GET['id'], FILTER_VALIDATE_INT);

"All that the xHTML validation shows is that you can lowercase and close your tags."


  • EdwinG
  • Registratie: oktober 2002
  • Laatst online: 16-09 22:10
Pendaco schreef op donderdag 21 oktober 2010 @ 20:55:
Waarom niet gebruik maken van de filter vars, dan kun je iig nog een range opgeven?
filter_var() is, helaas, niet perfect. Misschien dat het voor getallen goed werkt, maar vertrouw niet op de functie voor alle types die er, volgens de handleiding, mee te valideren zijn. Crisp heeft daar een mooie Blogpost over geschreven. (Deze post is uit juni 2009, ik weet niet wat er ondertussen aan filter_var() is veranderd)

Bezoek eens een willekeurige pagina


  • Patriot
  • Registratie: december 2004
  • Laatst online: 15-09 17:27

Patriot

Fulltime #whatpulsert

frickY schreef op donderdag 21 oktober 2010 @ 20:31:
[...]

Foute input is gewoon fout, ook als je er toch iets van zou kunnen maken.
Of voeg je ook 7 voorloop nullen toe als iemand 123 als telefoonnummer invoert?

Als iemand een ID moet geven dan moet je ook een ID eisen. Dan moet je niet de input zodanig gaan converteren tot je er een ID uit kunt herleiden.
Ik zie niet wat er mis is met het proberen fouten van de gebruiker te corrigeren. Het toevoegen van 7 voorlopnullen is onzin, maar een telefoonnummer dat in een internationaal format moest worden ingevuld maar is ingevuld in een nationaal format kun je in mijn ogen best proberen te corrigeren. Je moet de gebruiker weliswaar de kans geven zijn fout te corrigeren, maar de gebruiker daar een handje mee helpen is niet verkeerd.

de Tweakers-cookiewall is illegaal


  • RaZ
  • Registratie: november 2000
  • Niet online
Zo'n veld kan je inderdaad corrigeren. Maar de TS heeft het over dat ie het met elk veld eigenlijk doet.

Over het algemeen gooi je invoervelden in post, en niet get. De get heb je altijd zelf in de hand, zeker als het gaat om ID's. Als je dan eist dat iets nummeriek is, moet je nooit een string accepteren, en daar een nummeriek van maken.

Nu zeg je gewoon: "2a" == "2", en draai maar door. Nee, de input klopt niet, dus fout afhandelen..

  • RobIII
  • Registratie: december 2001
  • Laatst online: 19:14

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
Over het algemeen gooi je invoervelden in post, en niet get.
Vertel dat google even, die snappen 't schijnbaar nog niet ;) Met andere woorden: je snijdt de bocht hier zo krap dat je de hoekwoning kortwiekt ;)

http://www.cs.tut.fi/~jkorpela/forms/methods.html
RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
De get heb je altijd zelf in de hand, zeker als het gaat om ID's.
Care to explain? Hoe heb je een GET meer (of minder) "in de hand" dan een POST :?

[Voor 48% gewijzigd door RobIII op 21-10-2010 23:19]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • 327097
  • Registratie: november 2009
  • Laatst online: 03-07-2016
RobIII schreef op donderdag 21 oktober 2010 @ 23:14:
[...]

Vertel dat google even, die snappen 't schijnbaar nog niet ;)
Denk je niet dat GET opzettelijk gebruikt wordt zodat je meteen de juiste link kunt doorsturen voor bepaalde zoekresultaten?

  • RobIII
  • Registratie: december 2001
  • Laatst online: 19:14

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

JaHetIsChris schreef op donderdag 21 oktober 2010 @ 23:18:
[...]


Denk je niet dat GET opzettelijk gebruikt wordt zodat je meteen de juiste link kunt doorsturen voor bepaalde zoekresultaten?
Idempotence is het sleutelwoord ;)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • RaZ
  • Registratie: november 2000
  • Niet online
Uhm... Nee... Google doet dat ook niet.. Met Id's als bijvoorbeeld een pagina nummer.

Kijk op welke pagina hij staat, terwijl ik aangeef dat het nummer "3e" is. Dan krijg je gewoon pagina 1, en niet pagina 3. Google accepteerd dus die string niet als nummeric ;)

Hij negeerd hier gewoon de string, veld is niet nummeriek, dus pagina 1.

Klik

[Voor 8% gewijzigd door RaZ op 21-10-2010 23:25]


  • Darkstone
  • Registratie: mei 2009
  • Laatst online: 26-04-2014

Darkstone

Het kan altijd sneller.

tweakers doet het andersom:

http://gathering.tweakers.net/forum/list_messages/1430931/1P gaat gewoon naar pagina 2 van dit topic

'de sheet' -- Dell Latitude E6520, 1080p, i7-2820QM, X25-M 80GB, 16GB, 97Wh
Gezocht: Baan software development, C++, gave software, omgeving Delft.


  • RobIII
  • Registratie: december 2001
  • Laatst online: 19:14

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

RaZ schreef op donderdag 21 oktober 2010 @ 23:24:
Uhm... Nee... Google doet dat ook niet.. Met Id's als bijvoorbeeld een pagina nummer.
En de query zelf dan? Dat is namelijk een invoerveld en wordt gewoon in de GET gemikt! Oeh! Gevaarlijk! ;) Ik reageerde op (en quotte dus ook):
RaZ schreef op donderdag 21 oktober 2010 @ 23:11:
Over het algemeen gooi je invoervelden in post, en niet get.
Maar lees mijn linkje ook even; dan snap je wat ik bedoel. Dat google een ongeldig paginanummer niet vreet is terecht; daar heb ik het ook helemaal niet over. Of je get/post gebruikt heeft geen kont te maken met of de gegevens uit invoervelden komen (en wat met input type="hidden"? waar vallen die volgens jou onder?) maar met het feit of je enkel gegevens opvraagt of ook (potentieel) gegevens wijzigt. Idempotence.

[Voor 35% gewijzigd door RobIII op 21-10-2010 23:35]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • fleppuhstein
  • Registratie: januari 2002
  • Laatst online: 21-05 22:01
ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.
Licht eraan wat je er zelf mee doet, Onderstaand misschien een ideetje ?

PHP:
1
2
3
4
5
<?php
if(!((int) $_GET['g'] == $_GET['g'])) 
  throw new Exception('error');

?>

  • RaZ
  • Registratie: november 2000
  • Niet online
Ik snap je prima hoor.

Het gaat mij er om dat "2a" gewoon niet nummeriek is, als je dan dat wel eist, is de input dus invalid.

Zou het zelfde zijn als wachtwoorden case insensitive te maken voor het gemak van de gebruiker, wie weet staat caps-lock wel aan.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 17:20

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Sebazzz schreef op donderdag 21 oktober 2010 @ 20:06:
[...]

Als het gewoon gedocumenteerd is, dan is het prima gedrag. Zo werkt het gewoon in PHP.
Ja, ga de gebruiker van de webapp opzadelen met hoe PHP z'n gedrag documenteert |:(

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • Korben
  • Registratie: januari 2001
  • Laatst online: 16-09 19:31

Korben

() => {};

.oisyn schreef op vrijdag 22 oktober 2010 @ 03:00:
[...]

Ja, ga de gebruiker van de webapp opzadelen met hoe PHP z'n gedrag documenteert |:(
Ik ruik een nieuwe semi-standaard-header: X-Bullshit-Quirks-For. Resulteert in een pop-up in je browser 'pas op, deze website is geschreven in taal X, dus hou rekening met de volgende rare gedragingen: ...'.

OT, het is natuurlijk bullshit om te accepteren dat je nummers in elk arbitrait formaat mag schrijven. Niet in de laatste plaats omdat het zorgt voor problemen met caching en SEO. Overigens is is_numeric() waarschijnlijk niet voldoende, wat als ik bijvoorbeeld een request doe naar 'page.php?id=9437983489938498798379488947'? Dat pikt je database waarschijnlijk niet.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?


  • alex3305
  • Registratie: januari 2004
  • Laatst online: 17-09 09:47
ReenL schreef op donderdag 21 oktober 2010 @ 20:28:
[...]

Ik zie altijd graag of een array uit de url komt daarom pas ik de waarde in de _GET meestal gewoon aan:
PHP:
1
2
3
if ( !ctype_digit($_GET['a']) ) {
    $_GET['a'] = 0;
}

Maar dat is een kwestie van smaak.

[...]
Ik zou hier een variant op maken:

PHP:
1
2
3
4
5
6
if (is_numeric($_GET['a'])) {
    if (ctype_digit($_GET['a'])) {
        $value = $_GET['a']; return;
    }
}
$value = 0; return;


Waarbij je natuurlijk ook de $value kunt returnen :). Op deze manier controleer je namelijk eerst of het getal uberhaupt wel numeriek is, en wanneer dit het geval is, kijk je het een integer is.

  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
@fleppuhstein:
Dus hetzelfde als wat je met ctype_digit bereikt. het voorbeeld impliceerde ook dat je daarna de variable $a kon gebruiken.

@Korben:
Als het dan toch over veiligheid gaat, X-Bullshit-Quirks-For spoofen naar een andere taal, zodat een hacker de verkeerde zero-day uit de kast haalt :)

  • Hydra
  • Registratie: september 2000
  • Laatst online: 16-09 20:08
Om even terug te komen op de vraag van de TS: way back toen ik nog met PHP werkte had ik gewoon een UserInput class met een hoop methoden zoals getAsInt32($key) die ovor mij het casten en valideren van spullen uit de $_GET array afhandelden. Is je code een stuk leesbaarder dan met al die if-blokken.

https://niels.nu


  • Icelus
  • Registratie: januari 2004
  • Niet online
Houd er rekening mee dat ctype_digit alleen positieve getallen accepteert en geen spaties e.d.
Mogelijke oplossing:
PHP:
1
$id = ctype_digit( $_GET['id'] ) ? (int) $_GET['id'] : 0;

Developer Accused Of Unreadable Code Refuses To Comment


  • Gamebuster
  • Registratie: juli 2007
  • Laatst online: 17:35
Icelus schreef op vrijdag 22 oktober 2010 @ 10:33:
Houd er rekening mee dat ctype_digit alleen positieve getallen accepteert en geen spaties e.d.
Mogelijke oplossing:
PHP:
1
$id = ctype_digit( $_GET['id'] ) ? (int) $_GET['id'] : 0;
Misschien een trim erbij, als je toch bezig bent?

Let op: Mijn post bevat meningen, aannames of onwaarheden


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 17:20

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

ReenL schreef op donderdag 21 oktober 2010 @ 20:38:
@Gamebuster
Als je gewoon cast naar een int en iemand maakt een typo: 12`345 dan krijgt hij geen foutmelding maar dan gaat hij naar entry 12.
Vooral leuk als je geld overmaakt naar een andere bankrekening (goed, die stop je dan meestal weer niet in een int, maar ook daarvoor zou je kunnen zeggen: we parsen tot we een ongeldig teken tegenkomen, en dan accepteren we de input tot dan toe).

Gefeliciteerd trouwens ;)

[Voor 12% gewijzigd door .oisyn op 22-10-2010 11:47]

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
het is dus eigenlijk het besten om te kijken als het een nummer is en dan kijken als het in de range licht die jij wilt. Dus het handigste lijkt mij om zelf een functie hier voor te schijven die dat doet. En daar bvb is_numeric etc te gebruiken. Licht er aan wat jij zelf wilt.

En natuurlijk niet door gaan als er een "fout" op treed, dan de user het zelf laten verbeter natuurlijk.
Bedankt iedereen!

  • NMe
  • Registratie: februari 2004
  • Laatst online: 14:01

NMe

Quia Ego Sic Dico.

lauwsa schreef op vrijdag 22 oktober 2010 @ 18:01:
het is dus eigenlijk het besten om te kijken als het een nummer is en dan kijken als het in de range licht die jij wilt. Dus het handigste lijkt mij om zelf een functie hier voor te schijven die dat doet. En daar bvb is_numeric etc te gebruiken. Licht er aan wat jij zelf wilt.
Waarom een functie schrijven als er al een functie in het framework zit die doet wat je wil? En waarom haal je wéér is_numeric aan terwijl in de eerste paar posts van dit topic al gezegd is waarom die niet goed is om te kijken of een getal een int is, inclusief het alternatief dat sindsdien meerdere keren is aangehaald in dit topic? :?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
Ctype_digit dus...

@.oisyn
Thanks

  • lauwsa
  • Registratie: juli 2010
  • Laatst online: 01-08 09:30
oops, die bedoelde ik ook :$

Ik bedoelde met rang als je een getal tussen de 1000 en 1 nodig hebt dat je kijkt als hij daar in licht, dus dat hij niet een getal zoals 9999999999999999999 pakt omdat mysql dit waarschijnlijk niet zo leuk zal vinden :P

  • NMe
  • Registratie: februari 2004
  • Laatst online: 14:01

NMe

Quia Ego Sic Dico.

lauwsa schreef op vrijdag 22 oktober 2010 @ 18:54:
oops, die bedoelde ik ook :$

Ik bedoelde met rang als je een getal tussen de 1000 en 1 nodig hebt dat je kijkt als hij daar in licht, dus dat hij niet een getal zoals 9999999999999999999 pakt omdat mysql dit waarschijnlijk niet zo leuk zal vinden :P
BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.
Een unsigned bigint zou die waarde nog kunnen bevatten dus MySQL gaat er vast niet van schrikken als je dat intikt. Als je het in een normaal int-veld wil invoeren zonder verdere checks loop je wel kans dat MySQL de waarde als max int gaat opslaan, dus de maximale waarde die in een 32-bits intveld kan staan. ;)

Voor die range-check op integers kun je trouwens best filter_var gebruiken zodat je dus niet je eigen functie nodig hebt. Then again, kijken of het in int is met ctype_digit en vervolgens kijken of die int in een bepaalde range zit kost je 3 checks die allemaal op één regel passen, dus dat lijkt me geen probleem. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • theguyofdoom
  • Registratie: februari 2010
  • Laatst online: 15:08
Het idee is meestal dat POST data aanpast, en GET data ophaalt. Google volgt dus gewoon dit model.

Beide zijn eenvoudig aan te passen, alleen bij get gaat het makkelijker. Heb je nooit een zoekactie in de url veranderd, omdat de zoekfunctie niet op de resultatenpagina staat?
Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee