Hov. Du er ikke logget ind.
DU SKAL VÆRE LOGGET IND, FOR AT INTERAGERE PÅ DENNE SIDE

Hjælp til PHP UPDATE statement

Side 2 ud af 2 (15 indlæg)
Fra København
Tilmeldt 1. Jun 06
Indlæg ialt: 6114
Fra  Mikjaer Consulting ApS Skrevet kl. 17:29
Hvor mange stjerner giver du? :

Glen:
forstår dog stadig ikke Mikkel Mikjær´s udtalelse om at min database vender på hovedet

http://sv.wikipedia.org/wiki/Normalform_(databaser)

Tilmeldt 15. Sep 09
Indlæg ialt: 78
Fra  MJ Skrevet kl. 10:43
Hvor mange stjerner giver du? :

Hej Glenn,

Fedt at du prøver at lære at programmere - kritikken kan ofte lyde hård fra andre programmører, men man mener som regel det bedste ;-)

Jeg synes dit næste skridt som udvikler må være at kigge på biblioteker som PDO eller MySQLi. Jeg bruger personligt PDO, men du kan læse pros/cons her:

http://stackoverflow.com/questions/13569/mysqli-or-pdo-what-are-the-pros-and-cons

Der er mange fordele, foruden sikkerheden. Dit nuværende script er som mange nævner åbent for det der hedder 1. grads-injektion (1st order injection). Det er ikke umiddelbart åbenlyst for nye udviklere hvad skaden er, men problemet er, at en bruger ikke altid indtaster det data du forventer og som du sætter direkte ind i dit query. Hackere (nu bruger vi ordet bare for en god ordens skyld, selvom man dårligt skal være script kiddie for at udføre 1st order injections) kan sende data som ændrer dit query til f.eks. at spytte alverdens uønskede ting ud som du helst så ingen andre end du og brugeren selv vidste; Eller slette en hel masse data.

Hvis du insisterer på at gøre dit projekt færdigt med det nuværende MySQL-bibliotek skal du som minimum "escape" de data du sætter i query'et. F.eks.

mysql_query(sprintf('UPDATE t1 SET c1 = "%s" WHERE id = "%d"', mysql_real_escape_string($C1), mysql_real_escape_string($Id)));

Dette er stadig ikke en fuldkommen sikker løsning, men den klarer det meste.

PDO er afsikret for denne slags injections (så længe man bruger "prepared statements". Den rene "query" metode er ikke sikret!). Jeg vil dog bemærke at PDO er åbent for 2. grads-injektioner - det er dog i meget ekstreme tilfælde (kræver brug af særlig encoding og concatenation i queries)

Bemærk at "old school" MySQL-bibliotek du bruger er deprecated (fjernet) i PHP 5.6+.

Founder af hikingwebsitet www.trail17.com

Tilmeldt 4. Oct 13
Indlæg ialt: 99
Fra  Medieland.dk Skrevet kl. 15:43
Hvor mange stjerner giver du? :

Mark Jensen:

Hej Glenn,

Fedt at du prøver at lære at programmere - kritikken kan ofte lyde hård fra andre programmører, men man mener som regel det bedste ;-)

Jeg synes dit næste skridt som udvikler må være at kigge på biblioteker som PDO eller MySQLi. Jeg bruger personligt PDO, men du kan læse pros/cons her:

http://stackoverflow.com/questions/13569/mysqli-or-pdo-what-are-the-pros-and-cons

Der er mange fordele, foruden sikkerheden. Dit nuværende script er som mange nævner åbent for det der hedder 1. grads-injektion (1st order injection). Det er ikke umiddelbart åbenlyst for nye udviklere hvad skaden er, men problemet er, at en bruger ikke altid indtaster det data du forventer og som du sætter direkte ind i dit query. Hackere (nu bruger vi ordet bare for en god ordens skyld, selvom man dårligt skal være script kiddie for at udføre 1st order injections) kan sende data som ændrer dit query til f.eks. at spytte alverdens uønskede ting ud som du helst så ingen andre end du og brugeren selv vidste; Eller slette en hel masse data.

Hvis du insisterer på at gøre dit projekt færdigt med det nuværende MySQL-bibliotek skal du som minimum "escape" de data du sætter i query'et. F.eks.

mysql_query(sprintf('UPDATE t1 SET c1 = "%s" WHERE id = "%d"', mysql_real_escape_string($C1), mysql_real_escape_string($Id)));

Dette er stadig ikke en fuldkommen sikker løsning, men den klarer det meste.

PDO er afsikret for denne slags injections (så længe man bruger "prepared statements". Den rene "query" metode er ikke sikret!). Jeg vil dog bemærke at PDO er åbent for 2. grads-injektioner - det er dog i meget ekstreme tilfælde (kræver brug af særlig encoding og concatenation i queries)

Bemærk at "old school" MySQL-bibliotek du bruger er deprecated (fjernet) i PHP 5.6+.

Hej Mark

Tak for hjælpen, ja ville ville faktisk bruge en salgs preg_replace(tror jeg den hedder), men skal lige undesøge det du snakker om med ESCAPE.

Ja, jeg synes det er FEDT at lære, og har lært det utrolig nemt og hurtigt. På 1 år er jeg gået fra HTML og CSS til dette. Bruger meget youtube videotutorials og VTC.com videoer.   

Når jeg er færdig med det nuværrende projekt, så er jeg igang med at lave en BootStrap version til www.Medieland.dk. Fremoverover når jeg er blevet solid i PHP, MYSQL, CSS, skal jeg igang med ASP.NET eller Javascript......    Jeg synes det er SKIDE SJOVT ;-)    (RIMELIGT NØRDET)

Men ja, folk kan lyde hårde omkring min databse og kodning, men det må de selv om. Jeg er ligeglad, alt har jo en start :-)

Tak for din info


@MIKJÆR

Tak for linket omkring database

Fra København K
Tilmeldt 22. Aug 06
Indlæg ialt: 3348
Skrevet kl. 15:49
Hvor mange stjerner giver du? :

1. jeg er ikke sikker på at 3 er et gyldigt kolonnenavn

2. Tekststrenge "dsfsdfsf" skal pakkes ind så mysql kan forstå at det er en tekststreng.

3. Når du bruger det gamle mysql (som IKKE anbefales til nyudvikling længere), så kan du tjekke returværdien på mysql_query for at få din fejlmeddelelse, f.eks. mysql_query("update Lamers set lameness="HIGH" where name='Very big lamer'") or die(mysql_error());

Du kan nemt debugge queries ved at vise dem på din side og copypaste dem ind i en mysql klient.

f.eks. via 'echo "$q\n' - og så se om den query er gyldig efter du har gjort dine ting med din tekststreng.

Tilmeldt 15. Sep 09
Indlæg ialt: 78
Fra  MJ Skrevet kl. 16:01
Hvor mange stjerner giver du? :

Du bør helt klart kigge på preg (regular expressions) - det er korrekt det ofte bruges til validering af data (som man også bør bruge både for ens egen og brugerens skyld). Men i det "øjeblik" du indsætter tingene i en database er det korrekte at "escape" det (kort og godt gør man tegn der har en funktionel betydning i query'et, f.eks. " og ', til egentlig tekst og dermed "uskadelige").

Der to grunde til du nok ikke bør bruge preg_replace til at sætte ting i en database: Det er for det første langt mere vanskeligt at få tilrettet og/eller fjernet de potentielt skadelige tegn end at benytte en escape-funktion, og for det andet er regular expressions mere performance-intensive end alm. tekst-funktioner.

Så længe du bruger "old school" MySQL bør du gøre dette. Når du går over til prepared statements i PDO gør den det for dig* :-) Før i tiden havde man magic_quotes der gjorde det automatisk, men det forcerede nærmest dårlig kodepraksis og blev derfor fjernet for en del år tilbage.

*) Rent praktisk er query og data fuldkommen adskilt, så det er som sådan ikke fordi det er escaped. Data kan bare ikke påvirke query'et.

Helt enig :) Man bør altid lytte til de klogere, men serveringen er ofte ret kold.

Et par fede sites: Stackoverflow og Sitepoint. I min bog (næsten) uundværlige websites når man udvikler. Folk på SO er yderst passioneret og hjælpsomme og du kan finde svar på næsten alt.

Founder af hikingwebsitet www.trail17.com

Side 2 ud af 2 (15 indlæg)