$_SERVER['REQUEST_METHOD'], altijd 1 method?
Pagina: « vorige 1 2 3 volgende »
en unset($_REQUEST); werkt gewoon.
Ik ben een framework aan het bouwen en nu zou ik graag willen dat mijn GET parameters alleen via $_GET toegankelijk zijn.
Omdat de GET parameters ook in de $_REQUEST array zitten had ik bedacht om de $_REQUEST array te unsetten. Strak plan! :)
ECHTER!
Als ik de volgende url aanroep: www.mijnsite.nl/?TEST en ik vervolgens alle geregistreerde variabelen bekijk via "var_dump(get_defined_vars());" dan zie ik dat het woord TEST maar liefst 35!!! keer voorkomt! Schijnbaar wordt die GET variabele in allerlei andere server variabelen (zoals HTTP_X_REWRITE_URL, QUERY_STRING, HTTP_GET_VARS, argv) meegestuurd. Deze variabelen worden weer in een aantal overkoepelende variabelen meegestuurd waardoor uiteindelijk 35 keer TEST in de broncode voorkomt. Nu kan ik dus wel leuk die $_REQUEST array unsetten, maar nog steeds komt de GET variabele ruim 30 keer voor. Moet ik nu alle mogelijke opties waar die GET waarde in voorkomt gaan unsetten? Dat lijkt me allesbehalve handig. Wat nu? :(
Ozzie PHP op 10/01/2011 18:57:03:
Uit veiligheid. Stel ik roep $_REQUEST['id'] aan, en ik heb in zowel m'n COOKIE, POST als GET een id staan... da's niet handig. Vandaar dat ik 'm wil unsetten zodat ik altijd gericht (via POST, COOKIE of GET) een waarde moet opvragen.
Je kunt toch gewoon $_REQUEST niet gebruiken? Ik heb nog nooit last gehad van het bestaan van $_REQUEST terwijl ik hem nooit gebruik.
Dit is zoiets als de muur openhalen om het stopcontact waar soms 230 en soms 110 volt opstaat te verwijderen terwijl ik het toch nooit gebruik. En er al een bordje bij staat om het niet te gebruiken.
In OOP is het inderdaad gewoon dat je andere objecten niet aan jou data laat zitten. Je bied ze inderdaad dan een manier aan om toch aan bepaalde data te komen. Omdat PHP een taal is die niet per se OOP is kan je dat niet makkelijk afdwingen (kan waarschijnlijk wel).
Maar ook zie ik de reden niet waarom je het zou willen doen.
Als iemand anders met jouw framework moet gaan werken, dan heb je documentatie. In die documentatie kan die dan precies zien welke methodes er zijn en waarvoor.
Wat als jij dus strip_tags doet, maar die programmeur wel de html data wilt? Dat gaat dan niet.
Verder is het zo dat je eigenlijk ook geen eens strip_tags hoeft te doen als je data binnen krijgt, pas als je weer data weg doet naar de gebruiker hoef je zorgen te maken over die dingen.
"Wat als jij dus strip_tags doet, maar die programmeur wel de html data wilt?"
Je hebt gelijk, het was even een snel voorbeeldje.
"Verder is het zo dat je eigenlijk ook geen eens strip_tags hoeft te doen als je data binnen krijgt".
Stel dat je een forum hebt waarop mensen berichten kunnen posten, zou jij dan pas strip-tags doen bij de uitvoer? Lijkt me handiger om dit vooraf te doen zodat de gegevens "schoon" in de database staan.
Ozzie PHP op 13/01/2011 11:39:26:
Niet documenteren = niet bruikbaar = nutteloos om te maken"Als iemand anders met jouw framework moet gaan werken, dan heb je documentatie." Oh jij denkt dat ik dat allemaal ga documenteren straks? ;)
Ozzie PHP op 13/01/2011 11:39:26:
"Verder is het zo dat je eigenlijk ook geen eens strip_tags hoeft te doen als je data binnen krijgt".
Stel dat je een forum hebt waarop mensen berichten kunnen posten, zou jij dan pas strip-tags doen bij de uitvoer? Lijkt me handiger om dit vooraf te doen zodat de gegevens "schoon" in de database staan.
Stel dat je een forum hebt waarop mensen berichten kunnen posten, zou jij dan pas strip-tags doen bij de uitvoer? Lijkt me handiger om dit vooraf te doen zodat de gegevens "schoon" in de database staan.
Dat is weergave dus bij uitvoer. Je zorgt dat het veilig je database ingaat met de escape functie van je database. En je html veilig maken doe je bij de uitvoer.
"Dat is weergave dus bij uitvoer. Je zorgt dat het veilig je database ingaat met de escape functie van je database. En je html veilig maken doe je bij de uitvoer."
Oke, ik heb zelf geen IT achtergrond maar is dit een soort "stelregel" binnen het programmeren dat je iets pas veilig maakt bij de uitvoer?
Zelf zou ik als volgt denken, stel je hebt een forum en mensen mogen geen tags gebruiken. Het lijkt me dan handiger om de tags te strippen voordat je de reacties in de database zet. Waarom?
- de gegevens in de database zijn schoon
- tags worden gestript uit de reacties en dus nemen de reacties minder ruimte in beslag in de database
- alle duizenden, misschien wel tienduizenden of honderdduizenden reacties zijn bji uitvoer al goed en hoeven niet telkens bij iedere aanroep voor iedere bezoeker door de strip_tags functie gehaald te worden. Dat moet toch een behoorlijke performance winst opleveren zou ik zeggen.
Dus waarom niet vooraf strip_tags doen?
Ozzie PHP op 13/01/2011 11:39:26:
"Als iemand anders met jouw framework moet gaan werken, dan heb je documentatie." Oh jij denkt dat ik dat allemaal ga documenteren straks? ;)
Regel één van programmeren: Documenteer ALLES. Jij gaat echt over drie maanden niet meer precies weten wat alles betekende. Je zult dan dingen weer moeten gaan uitzoeken. Het lijkt misschien makkelijker, maar is het totaal niet.
Als je op een ICT-opleiding zit kan je code zelfs afgekeurd worden als je het niet goed hebt gedocumenteerd.
Ozzie PHP op 13/01/2011 11:39:26:
"Wat als jij dus strip_tags doet, maar die programmeur wel de html data wilt?"
Je hebt gelijk, het was even een snel voorbeeldje.
Je hebt gelijk, het was even een snel voorbeeldje.
Beter nadenken dan, als je geen voorbeeld weet te verzinnen is het ook niet logisch.
Ozzie PHP op 13/01/2011 11:39:26:
"Verder is het zo dat je eigenlijk ook geen eens strip_tags hoeft te doen als je data binnen krijgt".
Stel dat je een forum hebt waarop mensen berichten kunnen posten, zou jij dan pas strip-tags doen bij de uitvoer? Lijkt me handiger om dit vooraf te doen zodat de gegevens "schoon" in de database staan.
Stel dat je een forum hebt waarop mensen berichten kunnen posten, zou jij dan pas strip-tags doen bij de uitvoer? Lijkt me handiger om dit vooraf te doen zodat de gegevens "schoon" in de database staan.
NEE!
Fout. Je doet pas de strip_tags als je de data uit de database haalt. Je wilt de data inderdaad zo schoon mogelijk in de db hebben, dus laat je gewoon alles erin zitten wat iemand heeft geschreven. Misschien wil je het ooit wel eens omzetten naar een word bestand, dan maakt die html geen ene zak uit.
Alleen mysql_real_escape_string of typecast naar iets anders dan string als je iets in een database propt.
Ongedocumenteerde code kun je net zo goed weer weggooien als over een tijdje iets fout gaat ben je een eeuwigheid bezig om het op te lossen.
Je beveiligd het waar het voor nodig is en gaat niet onnodig data aanpassen. Als het in de database stopt zorg je dat het daarvoor veilig is. Wil je het naar de browser sturen dan maak je het daar veilig voor.
Je verprutst nu je data en als je het dan later anders nodig hebt baal je helemaal (bijvoorbeeld een gewone applicatie die uit de database leest of de tags die je moet aanpassen worden uitgebreid)
Eventueel kun je de geparsde tekst cachen maar dit doe je dan bij de invoer in bijvoorbeeld een extra kolom zodat als het wijzigt je de parsing overnieuw kunt doen.
Ozzie PHP op 13/01/2011 11:50:35:
"Niet documenteren = niet bruikbaar = nutteloos om te maken" Misschien wel ooit, maar zal er in 1e instantie voornamelijk zelf mee werken.
En dan ligt het even op de plank, kijk je d'r weer eens naar en dan denk je van 'Hmm, wat een aparte constructie, maar weer testen hoe het zat.' Je kunt niet alles onthouden, je bent geen computer, je hebt geen absoluut geheugen....
Ozzie PHP op 13/01/2011 11:50:35:
"Dat is weergave dus bij uitvoer. Je zorgt dat het veilig je database ingaat met de escape functie van je database. En je html veilig maken doe je bij de uitvoer."
Oke, ik heb zelf geen IT achtergrond maar is dit een soort "stelregel" binnen het programmeren dat je iets pas veilig maakt bij de uitvoer?
Oke, ik heb zelf geen IT achtergrond maar is dit een soort "stelregel" binnen het programmeren dat je iets pas veilig maakt bij de uitvoer?
Ja. De html heeft niks te maken met de database. Je moet alleen zorgen dat het veilig in de database kan vanuit de database gezien. Als je dan die data dan weer op een website wilt zetten, dan kijk je vanuit dat oogpunt en moet je zorgen dat het dan veilig is. Verder doe je geen verneuk functies zoals addslashes als je data in de database stopt.
Ozzie PHP op 13/01/2011 11:50:35:
Zelf zou ik als volgt denken, stel je hebt een forum en mensen mogen geen tags gebruiken. Het lijkt me dan handiger om de tags te strippen voordat je de reacties in de database zet. Waarom?
- de gegevens in de database zijn schoon
- de gegevens in de database zijn schoon
En verneukt. Ze zijn niet meer origineel. Rommel die ze uit de weilanden bij Moerdijk halen gaan ze ook niet eerst helemaal schoonmaken, dan is het geen valide data meer.
Ozzie PHP op 13/01/2011 11:50:35:
- tags worden gestript uit de reacties en dus nemen de reacties minder ruimte in beslag in de database
We leven in een tijd dat je terra- en petabyte (bijna) hardeschrijven hebt, en jij maakt je druk om een paar bytes?
Ozzie PHP op 13/01/2011 11:50:35:
- alle duizenden, misschien wel tienduizenden of honderdduizenden reacties zijn bji uitvoer al goed en hoeven niet telkens bij iedere aanroep voor iedere bezoeker door de strip_tags functie gehaald te worden. Dat moet toch een behoorlijke performance winst opleveren zou ik zeggen.
Nee. Strip_tags die werkt ontzettend snel. Als je nou nog een oude computer zou hebben, dan zou het misschien merkbaar zijn. Maar tegenwoordig...
Verder vergeet je dat je misschien helemaal geen strip_tags wilt.
Zou het logisch zijn om op een forum zoals phphulp strip_tags te doen?
Ozzie PHP op 13/01/2011 11:50:35:
Dus waarom niet vooraf strip_tags doen?
Daarom dus.
Zou je normaal willen quoten? Dit werkt onhandig.
Even voor de volledigheid. Ik documenteer mijn code wel... maar ik bedoel dat ik niet een handleiding ga schrijven (in ieder geval niet nu). Ik documenteer wel gewoon bij iedere functie in de code.
Ozzie PHP op 10/01/2011 16:03:35:
Ik wil die $_REQUEST uit veiligheidsoverwegingen juist niet gebruiken, omdat je dan niet weet waar de informatie vandaan komt.
"POST en GET gebruik je namelijk om andere redenen."
Wat bedoel je hiermee?
(even ander vraagje, als ik een variabele unset die niet bestaat kan dit dan kwaad?)
"POST en GET gebruik je namelijk om andere redenen."
Wat bedoel je hiermee?
(even ander vraagje, als ik een variabele unset die niet bestaat kan dit dan kwaad?)
Wat maakt dat nou weer uit? Een POST / GET waarde kun je altijd veranderen en aanpassen, dus in dat opzicht maakt het niet veel uit. Welke "veiligheidsoverwegingen" bedoel jij dan? Je kan mij denk ik niet overtuigen van een goede reden.
User-input behoor je standaard niet te vertrouwen en om die reden altijd te controleren. En dan maakt het niet uit of je GET, POST, PUT of welke methode dan ook gebruik. Als jij namelijk stiekem met een hidden formulier-veld iets wilt zetten, is dat gewoon aan te passen hoor :-)
"Welke "veiligheidsoverwegingen" bedoel jij dan? Je kan mij denk ik niet overtuigen van een goede reden."
Ik denk dat je gelijk hebt. Maar m'n bedoeling was eigenlijk om in m'n framework de GET en POST variabelen als volgt aan te moeten roepen $this->get('variabele') en $this->post('variabele') en dat het verder niet mogelijk zou zijn om op een andere manier die variabelen te verkrijgen. Dat was mijn insteek, maar het lijkt niet echt mogelijk te zijn.
De post data komt meestal van een formulier. Wat doet de gebruiker? Die vult het formulier in. Dus de postdata is aangepast.
Ozzie PHP op 13/01/2011 13:12:57:
Het gaat naar de client en komt dan van de client naar de server. Dan is het altijd makkelijker (en met bijvorobeeld urlparams voor firefox wordt het nog makkelijk ook http://urlparams.blogwart.com/share/index.php )"Als jij namelijk stiekem met een hidden formulier-veld iets wilt zetten, is dat gewoon aan te passen hoor :-)" hoe bedoel je? Een POST waarde kun je vanuit de browser toch niet aanpassen? Of bedoel je dat niet?
ALLES wat van de client komt is onveilig ($_POST,$_GET, $_COOKIE, $_FILES maar ook een deel van $__SERVER)
Installeer anders een fidler ( http://www.fiddler2.com/ ) zet het aan en bezoek een pagina. Alles wat je in fidler ziet staan is aan te passen want het komt van de client. (Ip adressen opslaan in de database zonder beveiliging kan al dodelijk zijn)
Ozzie PHP op 13/01/2011 13:12:57:
Ik denk dat je gelijk hebt. Maar m'n bedoeling was eigenlijk om in m'n framework de GET en POST variabelen als volgt aan te moeten roepen $this->get('variabele') en $this->post('variabele') en dat het verder niet mogelijk zou zijn om op een andere manier die variabelen te verkrijgen. Dat was mijn insteek, maar het lijkt niet echt mogelijk te zijn.
Ik vindt je $this->get en $this->post raar. Dat is toch geen onderdeel van je objecten? Hoogstens van een Request object.
edit:
$_FILES toegevoegd na tip van Karl
Gewijzigd op 13/01/2011 13:23:04 door TJVB tvb
Pagina: « vorige 1 2 3 volgende »