Aleksejs

Hmm, nez kāpēc man veikali ienāca prātā... :) Par veikaliem jau nebija ne runas :)

Nu, ja. Nē, nestrādāju Jēčepingā un arī diemžēl nevienu nepazīstu, kas tur strādātu.

Nu, es pieļauju domu, ka dati glabājas DB, vai ne? Tālāk pieņemu domu, ka katram no saitiem ir sava lokālā DB. Bez tam, droši vien pati CMS darbība noteikti ģenerē relatīvi mazu trafiku salīdzzinot ar pašiem web veikaliem. Droši vien ir daļas, kas attiecas tikai uz konkrētās valsts lapu, piemēram, komentāri par produktu lietuviski ir aktuāli tikai Lietuvā... Viena ideja, ka CMS veido 3 pieslēgumus uz attiecīgi lokālajām DB... Problēma tajā brīdī, ja kaut kas izpildās vienā DB bet neizpildās citā... Labāks risinājums droši vien būtu kopīgā master datubāze (kurā ir tās daļas, kas visām trim ir kopīgas), kurā tiek veiktas izmaiņas un šīs izmaiņas tālāk tiek replicētas uz lokālajām db. Jautājums, vai var replicēt tikai konkrētas tabulas?

http://www.jobsafari.se/jobs/it/jonkoping.shtml http://www.jobbsverige.se/includes/listing....cfm?cache=2608 http://csjobb.idg.se/Arbetsgivaren.nsf/Sea...rder=1&id=2 http://jobb.eniro.se/jobs/it/jonkoping.shtml http://jobb.monster.se/Search.aspx?q=&...amp;utf8=%C9%98 http://www.nyteknik.se/search/jobs.do;jses...11A5C73D0BA0BB6 http://www.offentligajobb.se/public_user/s...ionStateCode=06 http://www.stepstone.se/home_fs.cfm Saprotu, ka jautājums "Talar du på Svenska" nav jāuzdod... ;)

4e4en, jā, tas protams ir forši... Bet vai Tev ir arī kādi komentāri attiecībā uz site security policy? :) Pad mod_rewrite runājot: 1) Vai pāris KB fails neslogo sistēmu? 2) Vai ir izdevies izveidot analoģiju ar "permit allowed1; permit allowed2; ... permit allowedN; drop all;" vai arī viss ir līmenī "drop bad1; drop bad2; ... drop badN; permit all;' 3) Vai mod_security nebūtu piemērotāks rīks "sliktību" apstrādei logošanai utt, jo tomēr mod_rewrite nodarbojas tikai ar GET/HEAD.

Tāpēc, ka nepatīk dators, kas rūc pie auss un tāpēc, ka datoram pa nakti jāguļ, ja vien tas nav no servera dzelžiem būvēts.

ActionScript galīgi nav mans lauciņš, bet, kā būtu, ja norādītu arī otru parametru: on (release) { getURL("http://www.php.lv","_self"); }

Jā, es arī tajā otrajā esmu vīlies. Bet pirmais gan manuprāt diezgan sakarīgs :)

Atradu salīdzinājumus (par objektivitāti neņemos spriest - priekš tā katram sava galva uz pleciem) par dažādiem CA: http://www.whichssl.com/comparisons/compatibility.html http://www.sslshopper.com/certificate-authority-reviews.html

Vai gadījumā tu tos attēlus kādā veidā neapstrādā ar kādu php_skriptu pirms rādīšanas, varētu būt GD vai tamlīdzīga kļūda.

Rekur, black, ir izveidojis pakalpojumu, varbūt vari to izmantot... [edit] āāāāāā, rekur arī pakalpojums :D http://www.e-formas.lv/

Man atkal visu laiku ap bijušajām PSRS republikām. Pirmā ienāca prātā Armēnija un tad Azerbaidžāna, vēl pie sevis padomāju - tas gan būtu savādi ;)

Drosmīgie var iemēģināt arī šo: http://mywea.com.ar/ Nu, atzīstas, kurš momentā zināja, kurai valstij ir AR domēns? ;) Mani pirmie divi minējumi bija garām ;)

Es teiktu, ka attēli nav pilnībā pārkopējušies... salīdzini izmērus uz servera un uz sava datora. Bet var būt arī kas cits.

Parādi arī ko konkrēts vaicājums atgriež.

Klausi "ļauno jūzeri bubu" :D Bet vēl vēlams arī abu tabulu saturu (var tikai dažus ierakstus no katras), kas rada šo problēmu.

Nezinu, cik daudz/maz ir iespēju šim, bet ja nu kādam ir alerģija pret phpMyAdmin, bet ir nepieciešamas webisks MySQL administrēšanas rīks, tad varbūt ir vērts uzmest aci: http://sqlbuddy.com/

Kad lietotājs ielogojas, tad šo faktu piereģistrē kaut kur (piemēram, datubāzes tabulā). Kad lietotājs beidz darbu (vai sistēma viņu izmet dēļ dīkstāves), tad arī šo faktu piereģistrē kaut kur (piemēram, datubāzes tabulā). Attiecīgi, pēc tam kad lietotājs ir iegājis - katru reizi, kad viņam jāparāda lietotāju online skaits, tiek saskaitīti kaut kur (piemēram, datubāzes tabulā) reģistrētie ielogošanās fakti, par kuriem ir zināms, ka tiem vēl neatbilst kaut kur (piemēram, datubāzes tabulā) reģistrēti fakti, ka lietotājs izlogojies (vai izmests no sistēmas dīkstāves dēļ).

Vēl viens: http://www.websnapr.com/previewbubble/

http://www.sitepoint.com/article/anthology...-access-control http://www.sitepoint.com/article/users-php-sessions-mysql

Nu faktiski, jā, varam autentificēt arī sesijas ID, bet vienīgā problēma tad, ka nejauši aizverot pārlūku (vai nomainoties ip adresei) kods vairs nebūs derīgs, kas var izrādīties nelabi... (bet varbūt arī, ka tieši tas vajadzīgs...)

Nu daļēji šo visu varētu atrisināt sistēma, kad ID pats par sevi satur kādu kontrolsummu. Nu piemēram pēdējais cipars ir pirmo ciparu summa pēc moduļa 10. Un iekasēt nominālu maksu par īsziņas nosūtīšanu (galu galā cilvēks vainīgs pats, ka nav pareizi uzrakstījis), bet lielo pakalpojuma maksu iekasē tikai tad (un protams arī tikai tad nodrošina attiecīgajam ID pakalpojumu), ja sakrīt kontrolsumma - tam vajadzētu izslēgt kļūdas, kas maksā Latus, bet tajā pašā laikā ļautu nopelnīt pat uz neuzmanīgu lietotāju rēķina.

Kā izdzēšas? Es klients A redzu nosūti šitādu kodu: 123321 Kamēr es rakstu, tikmēr atnācis klients B, kuram gadās arī šis pats kods. Viņš izrādas ātrāks un aizsūta pirmais. Es aizsūtu, man nokāš naudu bet kods nav derīgs... Nav labi. Par varbūtību - varbūtība 1:999999 ir tikai un vienīgi viena lietotāja gadījumā. N lietotāju gadījumā ir daudz sliktāk. Varbūtību teorijā ir zināms tā sauktais "dzimšanas dienas paradokss|" - klasē, kurā ir 23 skolnieki varbūtība ka viņu dzimšanas dienas datumi sakrīt ir lielāka par 50% Tajā lapā ir arī formula N lietotāju gadījumam.

waplet, kas notiek ja diviem lietotājiem uzģenerējas viens un tas pats kods?

Bez A varianta nevarēsi iztikt, ja gribēsi pārdot tiem, kas nevēlas nekur reģistrēties.