andrisp Posted December 31, 2007 Report Share Posted December 31, 2007 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. Link to comment Share on other sites More sharing options...
Aleksejs Posted December 31, 2007 Report Share Posted December 31, 2007 Es parasti sūtu visus hex, oct skaitļu rakstītājus vienu māju tālāk, jo nekad nav bijusi vajadzība pieņemt šāda pieraksta veselos skaitļus. Link to comment Share on other sites More sharing options...
bubu Posted December 31, 2007 Report Share Posted December 31, 2007 sql injekcija nebūs iespējama, ja lietos mysql_escape_string. Tad var arī bez visādiem is_numericiem mierīgi iztikt. Link to comment Share on other sites More sharing options...
Aleksejs Posted December 31, 2007 Report Share Posted December 31, 2007 bubu, mysql_real_escape_string? Bez tam papildus piesardzīgam liek būt visi tie warningi, kas ir pieminēti: http://lv.php.net/manual/en/language.types.integer.php Link to comment Share on other sites More sharing options...
bubu Posted December 31, 2007 Report Share Posted December 31, 2007 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? Link to comment Share on other sites More sharing options...
andrisp Posted December 31, 2007 Report Share Posted December 31, 2007 (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 December 31, 2007 by andrisp Link to comment Share on other sites More sharing options...
Aleksejs Posted December 31, 2007 Report Share Posted December 31, 2007 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 ;) Link to comment Share on other sites More sharing options...
bubu Posted December 31, 2007 Report Share Posted December 31, 2007 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. Link to comment Share on other sites More sharing options...
andrisp Posted December 31, 2007 Report Share Posted December 31, 2007 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(). Link to comment Share on other sites More sharing options...
eregi Posted January 5, 2008 Author Report Share Posted January 5, 2008 šodien atradu to, ko man vajadzēja (: $kategory = Array ( '' => ''.t(Gallerys).' > ', 'gallery' => Array ( SORT_NUMERIC => ''.t(Gallerys).' > '.$page.'',) ); atbilde bij sort numeric (: Link to comment Share on other sites More sharing options...
bubu Posted January 5, 2008 Report Share Posted January 5, 2008 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. Link to comment Share on other sites More sharing options...
andrisp Posted January 5, 2008 Report Share Posted January 5, 2008 mjā, pievienojos bubu nesapratnei. Link to comment Share on other sites More sharing options...
eregi Posted January 6, 2008 Author Report Share Posted January 6, 2008 nu lainukā, bet man itkā iet (: iesakiet citu vaiantu Link to comment Share on other sites More sharing options...
bubu Posted January 6, 2008 Report Share Posted January 6, 2008 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. Link to comment Share on other sites More sharing options...
eregi Posted January 6, 2008 Author Report Share Posted January 6, 2008 Nečakarēju jūs, tam man nav iemesla. (: Lab, tā sabiedējāt, ka iztikšu ar ifiem un elseifiem. Link to comment Share on other sites More sharing options...
Recommended Posts