2easy

noņem tač pēdiņas!!! lai ir vnk $valoda_lv

tas, ka tu zini failu path un funkciju nosaukumus un pat redzi error messages, pats par sevi nav nekāds drauds drošībai. anyway "security thru obscurity" ir kkāda strausa taktika, un uz to nevar paļauties šī foruma sourci arī var dabūt apskatīt - folderi,faili,funkcijas nav nekāds noslēpums. endrju, uzliec sevi šeit par adminu, ja jau domā, ka esi tik kruts ^^ kamēr neesi atradis veidu, kā izmantot/ietekmēt koda loģiku tā, lai lapā atstātu paliekošas nevēlamas sekas, vai ticis pie datubēzes datiem, kuri tev nav paredzēti, tikmēr pāragri te lielīties ar pāris sīkumiem

jā, pareizi vsp jau pietiek ar to, ka pārbaudi un tas strādā ;)

diezgan specifisks jautājums, kuru ātrāk pašam būtu pārbaudīt ar print_r(apache_request_headers()); uz sev interesējošiem browseriem kko mēģini optimizēt trafikā?

oo izrādās MySQL tiešām tāds viegli ievainojams :D nju tikai tā konkrētā remote exploit ievainojamība attiecas uz 2 gadus senu versiju... labi vismaz, ka pašai apachei ir 0 vulnerabilities :)) anyway es riskētu. palūgtu adminam uzlikt jaunākos patchus, uztaisītu backup, un izmantotu remote. ja kāds kko sahakotu, tad atliktu backup un uzkodētu http/xml layeri... hai tad ir ;)

lai atšķirtu vai konkrētā rinda attiecas uz dzd vai vd, pieliec galā vēl vienu flag kolonnu, tipa Type SELECT vards, uzvards, MONTH(dzimene) menesis, DAYOFMONTH(dzimene) diena, 'dzd' AS Type FROM draugi WHERE DAYOFYEAR(dzimene) < '".(date('z')+60)."' UNION SELECT vards, uzvards, MONTH(vardene) menesis, DAYOFMONTH(vardene) diena, 'vd' FROM draugi WHERE DAYOFYEAR(vardene) < '".(date('z')+60)."'

plauktā jau viskas mētājās, bet kkā nesanāk palasīt. googlē visu var ātrāk atrast :D vsp pie sevis esmu pamanījis tādu prikolu, ka lasot drukātos medijus, bieži gribas uzspiest ctrl+f, bet nevar :D:D:D laikam tā jau ir kkāda diagnoze...

vispārīgāk runājot, es inputu iedalu 2x veidos 1) iekšējais - developer ierakstītās vērtības/konstantes, ko padod/izmanto funkcijās. kā arī tās vērtības, kas kkad ir ienākušas no ārpuses un pēc pārbaudes/apstrādes tgd ir drošas 2) ārējais - viss kas ir ienācis no ārpuses un vēl nav pārbaudīts (kad es teicu "user input", es domāju tieši par šo) jebkādam inputam neuzticēties būtu stulbi, jo ja pats neuzticies sev un vienai savai funkcijai liec vēlreiz pārbaudīt vērtības, ko padod cita tava funkcija, kas jau tās ir pārbaudījusi, tad tā ir kkāda pesimistiska paranoja. parasti plānojot applikācijas arhitektūru, drošības pārbaudēm ir savs līmenis, kurā tiek veiktas visas ar drošību saistītās darbības. bet citi līmeņi tālāk jau saņem drošus datus un var specializēties uz savu darbu tikai nesaki atkal, ka tas ir overheads. noteikti atradīsies kāds, kas par to nebūs aizdomājies :D btw, tas labi, ka lasi grāmatas ;)

tas tev ir viss skaidrs, bet te ir dafiga tautas, kuri vienus un tos pašus jautājumus pēc laika uzdod atkal. pieņem, ka tas overhead bija priekš viņiem ;) kādam vieglāk uztvert garus aprakstus ar atšķaidītu info, citam pietiek ar īsi un kodolīgi...

nav runa par int/float pielietojums ir vispārīgāks: skaitlis & teksts qn() saņem vērtību, kurai ir jābūt skaitlim (EDIT: ar skaitli šeit domāju gan int, gan float). ja padotā vertība nav skaitlis, tad pēc tam toč būs (EDIT: lietoju plašāko (float) castu, jo (int) kasts pakāstu decimāldaļas, bet šī funkcija ir domāta jebkuram skaitlim) qs() saņem stringu, un eskeipo to, ko vajag eskeipot

vai tad MySQLam ir drošības caurumi?

"aizsardzības sistēmas" izklausās pārspīlēti kruta. kkādu sistēmu ir vērts lietot tikai lapas auditam, lai ar automatizētu testu palīdzību mēģinātu atrast vietas, kur nav ievērota elementāra datu apstrāde/pārbaudes fabula ir ļoti vnkārša: nevajag uzticēties user inputam servera puses "drošībai" (pret sql injekcijām) lieto function qn($n) {return is_null($n) ? 'NULL' : (float) $n;} // sagatavo skaitli for mysql query function qs($s) {return is_null($s) ? 'NULL' : "'" . mysql_real_escape_string($s) . "'";} // sagatavo stringu for mysql query klienta puses "drošībai" (pret "html/css/js injekcijām" jeb xss) lieto htmlspecialchars() vārdu "drošībai" lieku pēdiņās, jo šīs lietas ir jāievēro arī pareizai datu apstrādei pat tad, kad drošību neviens neapdraud. piemēram 1) lai tabulā insertotu tekstu ar ', to vajag izlaist caur mysql_real_escape_string(), savādāk tas ' izraisīs mysql error, jo būs priekšlaicīgi aizvērts strings 2) lai lapā ziņas/jaunumu komentāros parādītu <, to vajag eskeipot ar htmlspecialchars(), savādāk tas nebūtu redzams, ja tam blakus būtu vēl kāds teksts, piemēram, <asdf kr4 tas, ka šī datu apstrāde ir saistīta arī ar drošību, tas ir tikai sekundāri

varbūt "treknajos gados" čalis ir atlicis savā kontā 200k-300k ne jau visi grāba kredītus vai visu nopelnīto tūlīt notrieca. dažiem pietiek saprāta padomāt pāris gājienus uz priekšu. var kaut vai papētīt vēsturi, kā dažādos laikos, dažādās valstīs plīsa burbuļi, un izdarīt secinājumus... piemēram, notikumi Japānā 80-tajos un 90-tajos gados http://en.wikipedia.org/wiki/Japanese_asset_price_bubble

šis paragrāfs neattiecas tikai uz valodas failiem, bet vsp: lai mazāk nodarbinātu serveri, lieto cache. tb uztaisi tabulu Cache, kur saglabā html kontentu - lapas daļas/fragmentus vai pat visu lapu no <html> līdz </html>. tad nākamajā reizē/pieprasījumā visi dati nav no jauna jāvāc kopā no vairākām tabulām. tāpat arī tos konstanšu failus inkludo tikai tad, ja pieprasītais kontents nav iekš cache, un šo kontentu vajag izveidot no jauna. statisks kontents var ļoti ilgi atrasties iekš cache, kamēr admins caur cms to nepamaina (pie šādām izmaiņām ir jānodzēš attiecīgā rindiņa Cache tabulā). savukārt dinamiski kontenti mainās biežāk, piemēram, pēc katra apmeklētāju pievienotā komentāra. tā kā SELECTi parasti ir ap 90% no visām db darbībām, tad šāds papildus menedžments ar Cache atmaksājas (kad perfromance ir svarīga) attiecībā uz include & define() performanci $gnTime = 0; function timeu() {list($sSecU, $sSec) = explode(' ', microtime()); return $sSec + $sSecU;} // izdod pašreizējo laiku: sekundes + mikrosekundes (aiz "komata") function timerSet() {global $gnTime; $gnTime = timeu();} function timerGet() {global $gnTime; return round(timeu() - $gnTime, 6);} function timerEcho($sInfo = '') {printf('%s%.4f<br />', $sInfo, timerGet());} // parāda laiku ar precizitāti līdz 100 mikrosekundēm (ilgākām darbībām). lielākas precizitātes mērījumiem desmitos mikrosekunžu (vai vēl mazāk) ir jāņem vērā arī pašas funkcijas izsaukuma laiks (tb tad būtu jāizmēra function call overhead) function constMk($iCnt) { // izveido valodas failu ar $iCnt konstantēm garumā 100-200 simboli ('a') $h = fopen('lng-' . $iCnt . '.php', 'w'); fwrite($h, '<?php' . "\n"); for ($i = 0; $i < $iCnt; $i++) fwrite($h, "define('_Tx-" . $iCnt . '-' . $i . "', '" . str_repeat('a', rand(100, 200)) . "');" . "\n"); fwrite($h, '?>'); fclose($h); } function constIncTimer() { // mēra konstanšu include performanci dažāda izmēra konstanšu failiem timerSet(); include 'lng-100.php'; timerEcho('100 const include: '); timerSet(); include 'lng-1000.php'; timerEcho('1000 const include: '); timerSet(); include 'lng-10000.php'; timerEcho('10000 const include: '); } constMk(100); constMk(1000); constMk(10000); // izpilda 1x, lai izveidotu testa datus (pēc tam aizkomentē) constIncTimer(); // izpilda daudzreiz, kamēr iegūst pietiekami ticamu vidējā laika novērtējumu /* aptuvens vidējais rezultāts uz mana pc: 100 const include: 0.0030 1000 const include: 0.0250 10000 const include: 0.2100 */ kā redzams 1000 konstantes (~170KB) uz mana pc inkludojas 25ms. manuprāt tas ir diezgan daudz tikai priekš konstantēm, jo uzskatu, ka visai lapas apstrādei servera pusē būtu jāpietiek ar dažiem simtiem ms, lai kopā ar ceļā pavadīto laiku userim izmaiņas lapā parādītos jau pēc 0.5s (max 1s). ok, ja ir daudz bildes, tās atnāk mazliet vēlāk, taču galvenais, lai html ātri būtu klāt. kr4 pēc iespējas vajag inkludot tikai to, kas ir nepieciešams, un nedarīt liekas darbības/muļķības. tad viss būs ātri ;)

vismaz man pilnīgi pietika ar manuāli http://www.php.net/manual/en/reference.pcre.pattern.syntax.php visas pamata lietas tur ir uzrakstītas. tiesa gan, kad es kkad mācījos par reg exp, ne jau uzreiz visu sapratu, kas tur uzrakstīts. pēc kāda laika pārlasot, var saprast vairāk. laikam zemapziņā tā info ar laiku sagremojas :D

tpc ka tas ir "2 in 1" :P

nu gan tā pateici, it kā tajā sourcē būtu sazin kādi dārgakmeņi, ko zagt...

laikam tāpēc jau ir nepieciešami tie palīgi, lai iedarbinātu to lohatronu ^^

un kas šajā veidā nav labs?

labāk ņem "lowest hanging fruit" (latviski idejiski tas būtu "iet pa vieglāko ceļu") imho, ar otru mysql connection ir daudz vieglāk paņemt datus nekā taisīt http konekciju un vienā galā formēt xml, lai pēc tam otrā galā parsētu xml. brrrr pat ja otrs db serveris fiziski būtu kkur citur/tālu, tad var arī atļaut piekonektēties no ārpuses un ņemt datus pa taisno, nevis caur kkādu http/xml layeri

šobrīd miegu ciet, tāpēc neko netestēju, bet savādāk pirmajā piegājienā mēģinātu šādi: pēc popup formas submita sagaidītu, kad pienāk atbilde, kur pozitīva rezultāta gadījumā būtu js, kas uzstāda jaunos select datus/options window.parent.document.getElementById("select-id").innerHTML = "<option value="val1">data 1</option><option value="val2">data 2</option>..."; window.close(); līdzīgi arī otrai darbībai: pēc bildes upload pienāk atbilde ar js window.parent.document.getElementById("img-id").src = "jaunais src"; window.close(); kr4 kkā tā, bet droši vien kkas nestrādās. vismaz tā parasti ir, kad netestē :D pēc idejas šajā gadījumā pat nekādu ajax nevajag, jo pietiek ar popup formas submit requestu

xmas12, ievērtē, kā citi taisa skriptu shopu http://codecanyon.net/category/all tur ir gan screenshoti, gan live preview, gan piemēri/apraksti/demo kā lietot skriptu, gan sistēmas prasības (info par failiem). var jau bez tā visa iztikt, taču šāda info viennozīmīgi ir tikai plus. tie, kam kādreiz ir bijusi negatīva pieredze "iepērkoties" kādā vietājā sms shopā, diez vai vēl pirks kādu failu, kuram ir tikai minimāla info. vnk vairāk info iedrošina tos, kas vēl svārstās un nezin, vai pirkt, vai nepirkt

iespējams, bet jāskatās konkrētāk. anyway, katrs jau pats novērtē savu darbu kā vēlas. imho, šajā gadījumā tās izmaiņas priekš suport varētu būt tik nesvarīgas, ka viņš vsp diez vai kko gribētu par to maksāt :P

mm laikam nav grūti uzminēt, ka balvā būs kāds sms shops ^^

Radio raksta ar īso "a" iesaku izmantot kkādu nebūt spellcheckeri pie produkta/skripta apraksta būtu labi, ja būtu arī bilde/screens, kur skripts ir redzams darbībā. sīkums, bet tomēr. vismaz rodas sajūta, ka tas skripts kkad ir arī strādājis ;)