[PHP/(My)SQL] voor dummies - Deel 61

quote:

Op zondag 3 augustus 2008 16:05 schreef Xcalibur het volgende:
I know

Ik werk ook wel met classes, alleen dat extenden is nog nieuw
Heb al even in de PHP documentatie gekeken, dat ziet er vrij overzichtelijk uit...

quote:

Op maandag 4 augustus 2008 20:29 schreef slakkie het volgende:
Waarom heb je de ID's nodig?

quote:

Op maandag 4 augustus 2008 20:30 schreef slakkie het volgende:
Chandler, moet je avatar trouwens m'n browser versie en OS raden?

quote:

Op maandag 4 augustus 2008 20:45 schreef Xcalibur het volgende:
nou, dat hoop ik niet, want ik zie IE7.0 / Windows XP terwijl ik op Safari op de Mac zit

Wat betreft on duplicate: ik zou on duplicate gebruiken, dan doe je in 1 query wat je anders in 2 queries doet
Waarom zou je het niet doen?

quote:

Op maandag 4 augustus 2008 20:48 schreef Chandler het volgende:

[..]

Voor mijn statistieken systeem ala ipcounter.nl, had in mijn nieuwe systeem vaak een probleem dat een uniek veld dubbel geschreven werdt. Even om duidelijk te zijn.

In het oude systeem deed ik.

Query voor kijken of item bestaat
JA -> fetch en return ID
Nee -> Insert en return mysql_insert_id()

In het nieuwe systeem heb ik dit allemaal verwijderd door de simpele INSERT INTO.... ON DUPLICATE KEY id = MYSQL_LAST_ID(id) waarbij de output precies het zelfde is, echter vraag ik me af of dit op den duur het systeem niet erg traag zou maken!?
[..]

quote:

Dat is inderdaad de bedoeling? zie je een fout gegeven dan?

quote:

Op maandag 4 augustus 2008 20:55 schreef slakkie het volgende:
Die vraag heb ik al eens beantwoord, maar je kan het in 1 query doen, waarom 2 queries gaan doen?
REPLACE INTO ip (ip, hostname) VALUES ('127.0.0.1', 'localhost').

quote:

Joh... XP en FF3 terwijl ik Ubuntu 6.10 / FF2.0.0.14 draai.

quote:

Op maandag 4 augustus 2008 21:05 schreef Chandler het volgende:
Mja het gaat mij er continue om om bepaalde ID's te achterhalen en te zetten, oftewel veel al insert en update wat ik dus nu in 1 query doe maar goed, ik vertrouw er nu op dat het niet zo goed is als eerst zoeken, dan plaatsen of uitlezen...

quote:

Mag ik jou useragentstring dan ook?

quote:

Op maandag 4 augustus 2008 21:18 schreef slakkie het volgende:
Je wilt geen update doen als het record gelijk is aan wat je gaat invoeren?

quote:

Zitten in je access logs.

quote:

Op maandag 4 augustus 2008 23:44 schreef Chandler het volgende:

[..]

In heel veel gevallen wil ik iets lezen, tenzij het niet bestaat dan invoeren. Laten we zeggen dat 95% uit lezen bestaat en 5% uit invoeren cq updaten.
[..]

Duidelijk

quote:

Op dinsdag 5 augustus 2008 12:14 schreef slacker_nl het volgende:

[..]

Je gaat daarna nog wat met het ID doen? Ik snap echt niet wat je nou precies aan het doen bent. Maar als je 95% van de tijd alleen interesse hebt in de ID's kan je net zo goed de ID opvragen en dan verder gaan, de overhead die je in met de overige 5% hebt is dan verder te verwaarlozen. In de huidige constructie ben je 100% bezig met read/write acties en anders ben je 95% read en 5% write acties aan het uitvoeren. De overhead van altijd updaten lijkt me meer wegen dan een tweede query voor een write actie.

quote:

Op woensdag 6 augustus 2008 17:03 schreef gieling het volgende:
Ik heb een probleempje, dus eerst maar even hier voorleggen.

Ik heb sinds kort een mac en daarop MAMP geinstalleerd... alleen als ik nu een script draai die postgegevens uit een form haalt, herkent hij de POST data niet. GET is verder geen probleem. Het script draait ook op een andere server dus het ligt zeker niet aan de code.

Iemand een idee waar het aan kan liggen?

quote:

Op woensdag 6 augustus 2008 17:27 schreef slacker_nl het volgende:
Ipv _POST en _GET kan je beter _REQUEST gebruiken... _POST en _GET zitten gewoon in _REQUEST:

http://nl3.php.net/manual/en/reserved.variables.request.php

quote:

Op woensdag 6 augustus 2008 17:37 schreef slacker_nl het volgende:
Dat lijkt me sterk...

Een URL met daarin debug info, zodat we kunnen zien wat er fout gaat?

quote:

Op woensdag 6 augustus 2008 17:44 schreef DionysuZ het volgende:
en verder zou ik me eens inlezen in sql injecties, want die code is erg vulnerable.

quote:

Op woensdag 6 augustus 2008 17:27 schreef slacker_nl het volgende:
Ipv _POST en _GET kan je beter _REQUEST gebruiken... _POST en _GET zitten gewoon in _REQUEST:

http://nl3.php.net/manual/en/reserved.variables.request.php

quote:

Op woensdag 6 augustus 2008 18:18 schreef Light het volgende:

[..]

$_REQUEST heeft ook nadelen. Je weet niet meer of een waarde via GET of POST (of COOKIE) geset is. En het is meer typen.

quote:

Op woensdag 6 augustus 2008 18:59 schreef slakkie het volgende:
Mja, _GET en _POST zijn nagenoeg hetzelfde, in JSP moet je ook een _get en een _post functie maken, waarbij je 9 vd 10 keer _get doorsluist naar de _post functie.

quote:

Op woensdag 6 augustus 2008 18:59 schreef slakkie het volgende:

[..]

Mja, _GET en _POST zijn nagenoeg hetzelfde, in JSP moet je ook een _get en een _post functie maken, waarbij je 9 vd 10 keer _get doorsluist naar de _post functie.

quote:

_COOKIE kan ik het nog begrijpen, maar je weet toch zelf wel waar je de value vandaan haalt...

En if ($_REQUEST['val'] == 'blaat') is korter dan: if ($_GET['val'] == "blaat" || $_POST['val'] == "blaat").

quote:

Op woensdag 6 augustus 2008 19:42 schreef Light het volgende:

[..]

_GET bevat alle variabelen die via de url (na het vraagteken) of via een formulier met method="get" worden meegezonden
_POST bevat alle variabelen die via een formulier met method="post" worden meegezonden. Da's niet hetzelfde.

Als je _REQUEST gebruikt kan ik een linkje bouwen dat hetzelfde doet als een formuliertje. Door dan iemand op dat linkje te laten klikken (klik hier om 1 miljoen euro te winnen), kunnen er dingen gebeuren die jij niet had voorzien. Het effect kan onbeduidend zijn maar ook tot gekkere dingen leiden.

quote:

Je moet dan ook of if('blaat' == $_GET['val']) of if('blaat' == $_POST['val']) gebruiken. En ja, ik heb de constante expres vooraan gezet in die vergelijkingen.

quote:

Op woensdag 6 augustus 2008 20:24 schreef slakkie het volgende:

[..]

_REQUEST geeft preference op _POST en niet op _GET, dus als jij data post en je zorgt dat de link ?val=bla bevat (om zo de data van _POST te overwriten) dan kom je bedrogen uit aangezien de _POST var voorrang heeft in de _REQUEST var. Dus waarom zou je dan in de problemen komen? Verder is het zo dat als je met _POST of _GET gaat werken dat je meer code moet kloppen (met debuggen gebruik je vaak een GET, en in live situaties ga je POST gebruiken). Jij moet voor deze twee gevallen extra code gaan kloppen terwijl ik alleen met _REQUEST gebruik en dus nergens m'n code hoef aan te passen.... Dus zowel met de GET als de POST kan ik op een generieke wijze overweg.

quote:

Uhm, ik zie hier iemand _POST en _GET door elkaar gebruiken, en m.i. moet je een call kunnen maken met zowel POST als GET en hetzelfde resultaat krijgen. _REQUEST is gewoon makkelijker, aangezien je je niet druk hoeft te maken over hoe de variablen in je request terecht komen, via GET of POST.

quote:

Het boeit mij verder niet waar je de constante neerzet, zolang ie maar aan de juiste voorwaarde voldoet.

quote:

Op woensdag 6 augustus 2008 21:07 schreef Light het volgende:
REQUEST bevat idd eerst GET en dan POST, als een variabele in beide geset wordt dan krijg je alleen de POST-waarde.
Het verwerken van formulierdata wil je meestal niet doen met variabelen die uit een GET komen. Voorbeeldje. Je hebt een formuliertje om dingen te verwijderen. Dat formuliertje gebruikt post en stuurt data (id=123) naar example.com/delete.php . In de verwerking wordt _REQUEST gebruikt.
Als ik dan iemand laat klikken op example.com/delete.php?id=123 ziet het formulier ook een id en wordt er dus ook iets verwijderd. En ja, het kan nog zo zijn dat voor die actie bepaalde rechten nodig zijn. Dan moet ik iemand met voldoende rechten op die link laten klikken. Da's niet zo moeilijk als het misschien lijkt.

Had je echter _POST gebruikt dan doet het klikken op het linkje niets, omdat er geen waarde via POST wordt verzonden. En ja, ik weet dat er meer manieren zijn en dat het ook mogelijk is om met bijvoorbeeld javascript een post-request uit te voeren. Maar je maakt het wel lastiger op die manier.

Ander voorbeeld. Stel je hebt een weblog waar bezoekers anoniem kunnen reageren. Dat gaat via een post-formuliertje. Iemand komt erachter dat het ook werkt als je de waardes in de url zet ipv via het formuliertje en zet die url op een forum ofzo. Gevolg, je krijgt 10.000 reacties van "anoniempje" met de tekst "slakkie is gek".

quote:

Op woensdag 6 augustus 2008 22:03 schreef slakkie het volgende:

[..]

Als je een delete.php form niet de GET accepteert maar in je code staat alleen dat het dmv POST opgestuurd wordt, dan klop je zelf wat stuut je een linkje op: http://opperschaap.net/ditwerktniet en zodra je daar op klikt wordt er een POST verzoek uitgevoerd naar example.com/delete.php met id=1234&hoedje=papier. Problem solved .

Kortom, als je vanwege security redenen iets niet GET zet maar in POST ben je enigsinds naief bezig. Je houdt misschien het beginnende lastpakje buiten de deur, maar anderen die iets meer verstand hebben kunnen die POST wel scripten en die proberen wel wat meer dan 10.000 keer zeggen dat ik gek ben (wat wel klopt overigens ).

quote:

Als je echt niet wilt dat bepaalde acties uitgevoerd worden dan ga je access toelaten op basis van IP adres (in Apache, of via je netwerk devices, etc), en zou je in de applicatie laag ook nog gebruik kunnen maken van ACL's (Xins is hier een voorbeeld van, daar kan je calls naar functies toelaten op basis van IP adresses, of je het nou via een GET of een POST uitvoert). En zo kan je van meer dingen gebruik maken om ervoor te zorgen dat er geen oneigenlijk gebruik wordt gemaakt van je systeem/applicatie.

quote:

Op woensdag 6 augustus 2008 22:36 schreef Farenji het volgende:

Als illustratie het vast wel bekende verhaal van iemand die een CMS had gebouwd, en daar alleen GET methodes in had gebruikt. Er werd een hele site ingezet, met veel data. Hij had er geen wachtwoord voorgezet, en het CMS werd op een gegeven moment gespiderd door Google. Gevolg: de hele site gewist. Want alle delete-knoppen waren gewoon linkjes met een GET querystring.

quote:

Op woensdag 6 augustus 2008 22:36 schreef Farenji het volgende:
Als illustratie het vast wel bekende verhaal van iemand die een CMS had gebouwd, en daar alleen GET methodes in had gebruikt. Er werd een hele site ingezet, met veel data. Hij had er geen wachtwoord voorgezet, en het CMS werd op een gegeven moment gespiderd door Google. Gevolg: de hele site gewist. Want alle delete-knoppen waren gewoon linkjes met een GET querystring.

quote:

Op donderdag 7 augustus 2008 09:15 schreef WyriHaximus het volgende:

[..]

Whehehehe . (Je kan me hier opvegen .) Is natuurlijk wel het ubervoorbeeld hoe het niet moet .

quote:

Op donderdag 7 augustus 2008 16:18 schreef Farenji het volgende:

[..]

Tja je zal de mensen de kost moeten geven... en de eerlijkheid gebiedt me te zeggen dat ik zelf ook wel zulke fouten heb gemaakt - al was ik altijd wel zo slim om er een wachtwoord voor te plempen

quote:

Op donderdag 7 augustus 2008 16:42 schreef Light het volgende:

[..]

Ik denk dat iedereen wel eens zo'n fout gemaakt heeft.

quote:

Op donderdag 7 augustus 2008 16:42 schreef Light het volgende:

[..]

Ik denk dat iedereen wel eens zo'n fout gemaakt heeft.

quote:

Op donderdag 7 augustus 2008 20:04 schreef SuperRembo het volgende:
Je vertelt niet wat precies de bedoeling is, en dat is meestal wel handig om te weten om te begrijpen of iets wel of niet "werkt". Welke tekens mogen er voorkomen in de string?

quote:

Je wil een streepje - gebruiken in een set, als die niet aan het begin of eind van de set staat, dan moet je die escapen met een backslash. Een set met letters, cijfers, streepje en gelijkteken wordt dan [a-z0-9\-=]. Deze set zet je in een string, daarbij moet je tekens als " en \ escapen met een backslash: "[a-z0-9\\-=]".

quote:

Is preg_match() niet sneller dan eregi()?

quote:

Op donderdag 7 augustus 2008 22:00 schreef DionysuZ het volgende:
[..]
En dat was juist het vreemde. Ik had eerst de - escaped met een \, maar toen deed hij het dus niet. Toen ik hem achteraan zette werkte hij weer wel.