Jump to content
php.lv forumi

Recommended Posts

Posted

Es parasti pārbaudu šādi (iekš funkcijām, kur tiek padots ID):

 

if (!is_numeric($id)) {
 return false;
}
$id = (int) $id;

 

Manuprāt, haki (ar domu - sql injekcijas) nav iespējami.

Posted

sql injekcija nebūs iespējama, ja lietos mysql_escape_string. Tad var arī bez visādiem is_numericiem mierīgi iztikt.

Posted

Man nekad nav bijusi problēma ar nereālo mysql_escape_string funkciju. Imho tas ir tikai svarīgi, ja tev konekcijas charsets ir tāds, kurā baits ar vērtību \0 vai ' vai " var būt sastāvdaļā no multi-byte charactera (utf-16, utf-32). Parastā ascii vai arī utf-8 tas nekad nenotiek.

 

Par kādiem warningiem ir runa?

Posted (edited)

bubu, piemēram, ja nebūs pārbaudīts vai $id ir int, tad šis izmetīs kļūdu gadijumā, ja nebūs int.:

$sql = "SELEC * FROM bla WHERE id = ".mysq_real_escape_string($id);

 

Un, protams, ka varētu arī iztikt bez tās is_numeric pārbaudes un vienkārši typecastot uz int, bet kaut kā drošāk ap sirdi, ja pārbaudu tomēr.

 

PS. bubu, varbūt paskaidrosi sīkāk par tiem baitiem un konekcijas charsetu ?

Edited by andrisp
Posted

Par warningiem attiecībā uz konvertēšanu un pārpildīšanos.

Vienkārši, šķiet labāk jau uzreiz visu maksimālu nogriezt un nevis, piemēram, vēlāk censties saprast, kādā veidā tas umņiks ar padotu oktālo skaitli varēja izlabot tādu lietu, kuru nedrīkstēja labot ;)

Posted

ah, nu labi jau labi. pēdiņās vēl to id vajag ielikt :) Protams, ka normāli tā nedara.

 

Par tiem čarsetiem - ja tev ir strings ar sekojošiem simboliem "abc", tad UTF-16BE čarsetā pa batiem tas izskatīsies kā a \0 b \0 c \0 (tb a = "a\0", utt). Un normālais escape tos 0-baitus eskeipos, kas nav pareizi. Jo serveris saņemts sekojošus baitus: a \ \0 b \ \0 c \ \0, kurus interpretējot UTF-16BE čarsetā iegūs pavisam citu stringu (pa čariem = a\, \0b, \\0, c\ un invalīds viens baits \0). real_escape turpretī saprastu, ka tās nulles nevajag eskeipot - tās pieder pie konkrēta čara.

 

Turpretī UTF-8 formātā \0 baits ir iespējams tikai un vienīgi, kur ir \0 čars. tātad tas tiks eskeipots pareizi. Tieši tāpat, piemēram, ar " pēdiņu. UTF-16 čarsetā divi baiti "" ir kautkāds unikodes čars. Un ja to eskeipo uz \"\", tad te jau sanāk pavisam invalīdi divi čari (viena vietā) ar vērtību \" (pa baitiem, ne čariem). UTF-8 turpretī garantē, ka baitu vērtības, no kurām sastāv multi-byte čarakteri vienmēr pieņem vērtības > 128. Tātad parastie ascii čarakteri (32-127) tajos nav.

Posted

Skaidrs, bet nu tāpat turpināšu izmanto real funkciju :)

 

Kaut vai tāpēc, ka:

This function became deprecated, do not use this function. Instead, use mysql_real_escape_string().

 

Tāpat arī, ja nu pēkšņi tiešām sistēmā ir jāmaina characterssets uz UTF-16 (maza iespēja, bet tomēr) ? Labāk tad jau uzreiz izmantot real.

 

Ja nepatīk garais funkcijas nosaukums, tad var (un īstenībā arī vajag, lai nākotnē būtu vieglāk nomainīt eskeipošanas metodiju, ja parādas nepieciešamība) izveidot wraper funkciju, piemēram, escape().

Posted

šodien atradu to, ko man vajadzēja (:

 

$kategory = Array ( 
	'' => ''.t(Gallerys).' > ',
	'gallery' => Array ( 
						SORT_NUMERIC => ''.t(Gallerys).' > '.$page.'',)
	);

 

 

atbilde bij sort numeric (:

Posted

Kas par murgu?

SORT_NUMERIC ir konstante, kas jāpadot sort funkcijām (tikai un vienīgi). Jebkur citur to izmantot ir bezjēdzīgi.

Posted

Te var gadīties kāda no šīm trīs lietām:

1) Vai nu mēs nesaprotam, ko tev tur vajag, un tu pats to esi salabojis (maz ticams)

2) Tu tur esi sarakstījis pats nezini ko, kas maģiskā veidā strādā, un tagad tu domā, ka SORT_NUMERIC bija tas risinājums (pilnīgi neiespējams variants)

3) Tu mūs čakarē.

 

Un tev jau augstāk (iepriekšējā lapusē) piedāvāja visādus variantus. Manuprāt tie visai labi derēja tavai situācijai, kuru varēja mēģināt saprast no tava nesakidrā apraksta.

×
×
  • Create New...