Problemer med Opera og ZenCart-tillegg - Hjelp belønnes! :)

[magnusalex]

Hei,

 

Kort fortalt: Har i en lengre tid skrevet en del custom kodetillegg til ZenCart. Holder nå på med testing i sluttfasen. Sliter litt med Opera som nettleser på et par av kodene. Noen som gidder å ta en kjapp titt å se om det er noen åpenbare feil?

 

Begge disse kodesnuttene ligger i samme fil. "Backend":

<?php $con=mysql_connect('localhost','********','********');
mysql_select_db('********', $con);

$produktid = (int)$_GET['products_id']; 

$query = "SELECT categories_name FROM products_to_categories AS p, categories_description AS c WHERE p.categories_id = c.categories_id AND p.products_id = $produktid";
{
$result = mysql_query($query) or die(mysql_error());
}

?>

"Frontend":

<table border="0" cellpadding="0" cellspacing="1">
<tr><td>

<form><select>

<option>Sjekk liste for flere...</option>
<?php while($row = mysql_fetch_array( $result ))
{ ?>
<option value="<?=$row['categories_name'];?>" <?php if($row['categories_name']==$produktid) echo "selected";?>>
<?=$row['categories_name']; ?></option>
<? } ?>

</select></form>

</td></tr>
</table>

 

Dette brukes som nevnt i ZenCart. Funksjonen er enkelt å greit å vise hvilke andre kategorier et produkt er linket opp til. Funksjonen i seg selv virker, og en dropdownmeny genereres, problemet som oppstår er ganske nøyaktig:

 

Dersom denne koden blir inkludert tidlig i produktinfo-visningen, før kodesnutten som genererer en Kjøp-knapp, slutter Kjøp-knappen å virke. Man får trykket på den, men ingen varer legges i handlevognen. Trodde først jeg hadde glemt å avslutte formen etc, men det var det ikke. Problemet oppstår KUN i Opera, alle andre nettlesere fungerer fint.

 

Noen forslag?

 

Dersom det er nødvendig med et eksempel, ligger koden live på et produksjonsnettsted. Kan gjerne gi info over PM. Om noen kan biddra med en løsning, kan jeg tilby både rabatter og gratisprodukter i butikken det gjelder. Garanterer at du finner noe i butikken du har behov for, med over 5000 forskjelige produkter

[Jonas]

Haha, fat chance - ingen kommer til å komme frem til en løsning på bakgrunn av det lille du forteller oss. Legg ut linken, du. Dette har forresten ingen verdens ting med PHP å gjøre, annet enn koden den genererer. Ellers kan jeg tipse om W3s HTML-validator.

 

PS: Ikke bry deg med å sende den til meg. Driver ikke personlig service slik du spør etter.

[magnusalex]

Aiai... Stått opp på feil bein i dag?

 

Vel, ser ikke helt poenget med å legge ut linken. Den vil ikke vise noe mer enn det jeg har postet heller. Spørsmålet mitt var egentlig ganske enkelt, er det noen åpenbare feil i den koden som kan få en annen form til å slutte å virke? Som nevnt tidligere: ALT fungerer som det skal. Denne koden også - bare ikke i Opera.

 

Du trenger heller ikke å ta bryet med å svare vet du, om du ikke har noe mer nyttig å komme med. Jeg vet godt hva W3s validator er, den er også forsøkt for lenge siden.

 

Vil gjerne ha en forklaring på hvorfor det ikke har noe med php å gjøre, når hele ZenCart og koden i seg selv er bygget med php og mysql?

Endret 4. februar 2010 av magnusalex

[Jonas]

Vil gjerne ha en forklaring på hvorfor det ikke har noe med php å gjøre, når hele ZenCart og koden i seg selv er bygget med php og mysql?

ZenCart kan for alt jeg vet være drevet av apekatter som febrilsk taster HTML ved hvert page-request. Poenget er at det er HTML de trykker og det er kun den som til syvende og sist bestemmer hva nettleseren gjør. Bugs slik du beskriver kan være forårsaket av de merkeligste ting og de er ofte langt ifra åpenbare. Det er fullstendig umulig å debugge uten å ha problemet foran seg.

Endret 4. februar 2010 av Jonas

[quantum]

Vil gjerne ha en forklaring på hvorfor det ikke har noe med php å gjøre, når hele ZenCart og koden i seg selv er bygget med php og mysql?

 

Han mener nok at browseren ikke ser snurten av php-koden. Det er html'en som er problemet (selv om den riktig nok kan være produsert av php, eller en gjeng apekatter, for den saks skyld. Personlig tror jeg apekattene skriver php-koden og ikke html'en), det sier seg selv at det er meningsløst å gi noe tips når du bare vil vise fram litt php-kode som produserer et lite fragment av den siden som Opera ikke liker.

[TheClown]

Vedder på at det har noe med javascript å gjøre

[qualbeen]

PHP genererer samme html for alle browsere. Så når én browser ikke liker HTML-koden, skyldes dette ikke PHP, men selve HTML-koden. Og da trenger vi _all_ html-kode for å klare å debugge. PHP-koden er i grunn irrelevant i denne sammenheng.

 

Gi oss en url!

[Even_A]

Dette hjelper deg lite med problemet ditt, men vil påpeke en sikkerhets mangel du har i sql spørringen din. Husk at folk kan skrive hva som helst i formen/url'n slik at "skadelig kode" kan forekomme. Bruk derfor alltid mysql_real_escape_string() i spørringene dine. Mer info finner du på: http://php.net/manual/en/function.mysql-re...cape-string.php.

 

*pirke, pirke*

[Martin A.]

Dette hjelper deg lite med problemet ditt, men vil påpeke en sikkerhets mangel du har i sql spørringen din. Husk at folk kan skrive hva som helst i formen/url'n slik at "skadelig kode" kan forekomme. Bruk derfor alltid mysql_real_escape_string() i spørringene dine. Mer info finner du på: http://php.net/manual/en/function.mysql-re...cape-string.php.

 

*pirke, pirke*

Nja, ikke helt sant det vel. Produkt IDen blir validert til integer, og er det noe annet enn heltall returnerer den 0. "3<script>farlige greier her</script>" vil returnere 3.

 

Forøvrig er det ikke spesielt vanskelig å finne websiden dette ligger på. Et raskt Google-søk på "Sjekk liste for flere..." viser meg denne siden. Kan ikke se noen direkte feil, annet enn at <select> mangler name="", men det burde ikke gi noen problemer.

[TheClown]

Er det forskjell på int() og is_numeric() ?

[qualbeen]

is_numeric() er en boolsk funksjon som returnerer true/false, avhengig av om variablene kan tolkes som en nummer-verdi eller ei. is_numeric() endrer ikke oppgitt variabel. Det å caste til integer derimot, endrer verdien til et heltall (ingen endring skjer om variabelen allerede er av numerisk type).

 

Mao en temmelig vesentlig forskjell

[Even_A]

Hadde fortsatt brukt mysql_real_escape_string. Mange tror at f.eks: is_numeric vil være en "safe" validering, men husk at ting som 04x56 vil gi true (ikke testet akkurat den, men den failer på masse).

 

Vet ikke om int er 100% trygt, men går utifra at du vet det? Som hovedregel skal man både validere OG escape hver string som skal i en spørring. Ja, jeg er paranoid! Om prosjektet ditt inneholder privat data som personopplysninger ber jeg deg pent om å være litt "føre var". Er så mye crap protection på diverse nettsider:/

[nomore]

Validering må ikke feiltolkes for å være den eneste sikkerheten som trengs for å unngå SQL-injections. Men casting( (int) ) er ikke validering, det er "konvertering". Ved å skrive (int)$medlem_id så vil man med "15;DROP DATABASE medlemmer" ende opp med 15, og med ";DROP DATABASE medlemmer" vil man ende opp med 0. Så casting er ansett for å være godkjent i forhold til sikkerhet.

 

Men det skader ikke å validere dataene i tillegg

[qualbeen]

[...] Så casting er ansett for å være godkjent i forhold til sikkerhet. [...]

Mulig jeg mistolker setningen din; om den er skrevet spesifikt som svar til denne problemstillingen, skal jeg ikke dvele mer ved det.

 

Er det derimot slik at du mener på generelt nivå at casting er en godkjent sikkerhetsmekanisme, krever jeg litt mer dokumentasjon rundt dette, før jeg kjøper påstanden.. Har svært sjeldent hørt om casting i sikkerhetsøyemed, og baserer aldri mine sikkerhetsrutiner på casting!

[nomore]

Vel, nå er sikkerhet så mangt, men casting er sånn sett godt brukendes til denne problemstillingen

[Ernie]

Hadde fortsatt brukt mysql_real_escape_string. Mange tror at f.eks: is_numeric vil være en "safe" validering, men husk at ting som 04x56 vil gi true (ikke testet akkurat den, men den failer på masse).

 

Vet ikke om int er 100% trygt, men går utifra at du vet det? Som hovedregel skal man både validere OG escape hver string som skal i en spørring. Ja, jeg er paranoid! Om prosjektet ditt inneholder privat data som personopplysninger ber jeg deg pent om å være litt "føre var". Er så mye crap protection på diverse nettsider:/

is_numeric for å finne ut om noe er numerisk er en helt trygg metode for å finne ut om noe er et tall når det skal inn i MySQL. Det er bare du som ikke veit hva MySQL faktisk kan ta inn av tall At 0x... gir true gir absolutt ingen problemer. 0x angir tall i 16-tallsystemet, noe også MySQL godtar inn. Tall på formen xEy (f.eks 3.2E2 som er 320) er heller ingen problemer. Kort sagt, alt is_numeric godtar som tall godtar også MySQL som tall.

 

... og ja, casting av en streng til int holder mer enn nok for å gjøre data inn trygt for en database. Er det ikke et heltall får man en 0 tilbake, og det skaper sjeldent problemer for noen.

Endret 8. februar 2010 av Ernie