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

quote:

Op dinsdag 6 januari 2009 12:19 schreef Tuvai.net het volgende:

3) Je script is erg vatbaar voor SQL Injection; je gebruikt immers rechtstreeks een variabele die gebruik maakt van een $_POST waarde zonder hier ook maar enige controle op uit te voeren.

Vooral dit is een goede Kerol. Want wat zal er gebeuren als iemand als username "';DELETE FROM `members` WHERE 1 OR `username` = '" invult?

Juist, dan krijg je dit...



En weg zijn al je members :)

quote:

Op dinsdag 6 januari 2009 12:57 schreef Roy_T het volgende:

[..]

Vooral dit is een goede Kerol. Want wat zal er gebeuren als iemand als username "';DELETE FROM `members` WHERE 1 OR `username` = '" invult?

Juist, dan krijg je dit...
[ code verwijderd ]

En weg zijn al je members

Lees de documentatie bij mysql_query eens goed

quote:

Op dinsdag 6 januari 2009 12:58 schreef GlowMouse het volgende:

Lees de documentatie bij mysql_query eens goed

Details

Ondanks dat dit inderdaad niet werkt, is het natuurlijk wel degelijk gevaarlijk om data richting je query niet te escapen (dat weet jij ook wel, maar ik stress het even voor Kerol ).

Daarom gebruik je PDO...

quote:

Op dinsdag 6 januari 2009 14:53 schreef slacker_nl het volgende:
Daarom gebruik je PDO...

Helaas zijn er teveel hosts die dat niet ondersteunen, net als mysqli.

Dan ga je weg bij die hosters, maak duidelijk dat je weggaat omdat ze die features niet ondersteunen en dan gaan ze vanzelf wel een keer die meuk ondersteunen.

Of doe zoals ik, huur je eigen doos.

quote:

Op dinsdag 6 januari 2009 14:56 schreef slacker_nl het volgende:
Dan ga je weg bij die hosters, maak duidelijk dat je weggaat omdat ze die features niet ondersteunen en dan gaan ze vanzelf wel een keer die meuk ondersteunen.

Dat is leuk gezegd, maar je hebt niet altijd invloed op het platform waar je applicatie op wordt geïnstalleerd.

Dat betekend overigens wel dat je hoster geen PHP 5.x draait. Das alleen al reden genoeg om naar een andere hoster over te stappen of te adviseren om te zoeken naar een andere hoster.

quote:

Op dinsdag 6 januari 2009 16:35 schreef slacker_nl het volgende:
Dat betekend overigens wel dat je hoster geen PHP 5.x draait. Das alleen al reden genoeg om naar een andere hoster over te stappen of te adviseren om te zoeken naar een andere hoster.

Jij hebt het steeds over hosters, Tijn over platformen. Een hoster host wel op een bepaald platform, maar een platform hoeft nog niet bij een host te horen. Ik heb bijvoorbeeld een klant die naast enkele honderden servers met PHP5 ook nog honderden bakken heeft met PHP4, puur omdat er ook legacy spul op draait (en zo nog meer redenen). Die hebben uiteraard geen host, maar een eigen team van systeembeheerders met daarboven weer architecten. Ik kan nog zo graag PHP5 willen, maar als ik daar op een cluster met PHP4 kom dan breng ik er niets tegenin

Misschien zit PDO dan wel bij PHP 5 standaard, maar wat nou als de hoster het er uit haalt? Doen er ook zat.
En in PHP 6? Er gaan geruchten dat mysql_* en mysqli_* dan niet meer bestaan.... ai daar gaat je website.
Wat doe je dan?
Misschien alleen voor de meer gevorderde, maar je maakt een eigen database-klasse, los van welk database-systeem je hebt. Je kunt hierbij denken aan functies als select(), edit(), count(), insertedID(), etc.. en daar verwerk je een functie in, die je query beveiligd:
array select(string $query, array $variables)
daar kun je het beveiligen, als je PDO hebt is dat simpel, als je geen PDO hebt met mysql_real_escape_string() of intval(), net erna welk type het is.

gaan we nu even kijken:
Je hebt het in PDO gemaakt en je zet het over naar een host zonder PDO...even scriptje omzetten en je hebt het.
Je hebt het met mysql_* gemaakt en je wilt het in PDO hebben, want je wilt overgaan naar PHP 6...even scriptje omzetten.....
zie je? veel handiger

Hopelijk hebben sommigen er iets aan

mvg
Marco

^{Dit bericht is niet gericht op een persoon, maar als algemene informatie als toevoeging bij het huidige onderwerp. Eventuele opmerkingen die je persoonlijk kunt opvatten moet je zo dus niet opvatten.}

Ik denk dat velen hier al een dergelijke abstractielaag gebruiken (zelf geschreven, of omdat ze een framework gebruiken) Niettemin een prima tip!

Ik heb een vraag mbt de bouw van een webshop.

Hoe zouden jullie de data van een bestelling in de database opnemen?

Een tabel met;
- klant_nummer, product_nummer, prijs
- klant_nummer, product_nummer, product_naam, product_gewicht, prijs

Het voordeel van optie 2 is dat als er een productnaam wordt gewijzigd (of zelfs verwijderd), dat alle info wel in de bestelling blijft staan.

Het gaat om flink wat bestellingen per dag.
Graag jullie idee hier over!!

Ik zou gaan voor optie twee, al zijn product_naam en product_gewicht natuurlijk enigzins redundante datum en zou je als een product wijzigt eigenlijk een nieuw product moeten toevoegen aan de database en het oude product een 'niet actief' tag mee moeten geven.

Maar dat hangt van je hele datamodel af.

Weet iemand zo even uit zijn mouw te schudden hoe je middels een query (mysql) gebruikers kunt vinden waarbij de gebruikersnamen beginnen met een cijfer (0-9). Met letters lukt simpel LIKE 'B%' maar ik wil nu alle gebruikers die gebruikersnamen hebben met 0-9

WHERE lala REGEXP '^[0-9].*'

Das wel een complexe functie die lala

quote:

Op donderdag 8 januari 2009 11:20 schreef GI het volgende:
Das wel een complexe functie die lala

Geen idee, ik ben niet zo goed in regular expressions. Of zit ik helemaal fout met dat 'ie REGEXP moet gebruiken?

quote:

Op donderdag 8 januari 2009 11:17 schreef Chandler het volgende:
Weet iemand zo even uit zijn mouw te schudden hoe je middels een query (mysql) gebruikers kunt vinden waarbij de gebruikersnamen beginnen met een cijfer (0-9). Met letters lukt simpel LIKE 'B%' maar ik wil nu alle gebruikers die gebruikersnamen hebben met 0-9

met REGEXP in MySQL

=edit=
casten levert teveel 0-en op

Ik deed bijdehand met het noemen van het veld 'lala' verder zou ik het niet weten en ben ik een regexp n00b.

quote:

Op donderdag 8 januari 2009 11:20 schreef HuHu het volgende:
WHERE lala REGEXP '^[0-9].*'

Werkt idd perfect, had zelf een andere versie met % maar dat werkte natuurlijk niet

Je kunt denk ik ook WHERE veld BETWEEN '0' and '9' gebruiken. Als het werkt, kan het in ieder geval gebruik maken van indices, hoewel ik niet denk dat je daar winst mee boekt tenzij er weinig gebruikers zijn die hun username met een getal laten beginnen.

quote:

Op donderdag 8 januari 2009 11:36 schreef GlowMouse het volgende:
Je kunt denk ik ook WHERE veld BETWEEN '0' and '9' gebruiken.

Nee dus.

quote:

Op donderdag 8 januari 2009 12:17 schreef Tuvai.net het volgende:

[..]

Nee dus.

'9adsf' gaat fout Kun je nog >='0' AND <':' gebruiken.

quote:

Op donderdag 8 januari 2009 07:29 schreef jeroen2497 het volgende:
Ik heb een vraag mbt de bouw van een webshop.

Hoe zouden jullie de data van een bestelling in de database opnemen?

Een tabel met;
- klant_nummer, product_nummer, prijs
- klant_nummer, product_nummer, product_naam, product_gewicht, prijs

Het voordeel van optie 2 is dat als er een productnaam wordt gewijzigd (of zelfs verwijderd), dat alle info wel in de bestelling blijft staan.

Het gaat om flink wat bestellingen per dag.
Graag jullie idee hier over!!

Ik zou voor het eerste gaan om de volgende reden:

Als de naam van je product (typo) of prijs verandert, en je hebt een link naar je productnummer, wordt da overal weer correct aangepast. Afhankelijk van de situatie wil je dan de prijs wel/niet aanpassen. Ik denk dat je in zon geval bij bestellingen de prijs aan wil passen, en als een bestelling betaald is (dan is het ook geen bestelling meer maar een factuur) dat je alles wil fixeren.
Data redundant opslaan blijft imo tenzij het duidelijke voordelen heeft. In dit geval zie ik het voordeel totaal neit. Het scenario wat jij schets met producten die verwijderd zijn zou ik oplossen door producten niet uit je database te gooien (is sowieso een slecht idee ivm commercie), maar door ze inactief te maken.
En natuurlijk kan je na x jaar je productentabel opschonen door alle inactieve dingen van meer dan x jaar oud weg te gooien.

Ik zou het wel redundant opslaan, en dezelfde tabel gebruiken voor "bestellingen" en "facturen". Het is namelijk precies hetzelfde, alleen is bij de ene "payed" false en bij de andere true.

Waarom zou je de prijs aan willen passen nadat een product besteld is maar nog niet geleverd? Stel dat je iets bestelt voor 10 euro, 10 minuten later maakt de admin dat product 20 euro en wanneer de bestelling wordt afgehandeld is de klant opeens het dubbele kwijt.

Data redundant opslaan lijkt me in dit geval een duidelijk voordeel hebben: het is 100% gelijk aan het moment waarop er besteld werd.

Ik zou overigens wel een aparte tabel maken voor orders (dus bestellingen), met hierin het klantnummer, afleveradres, status, etc. en een tabel met order_items (ofzo) die weer aan orders hangen.