krikulis

Par ram drive labāks būs memkešs. TCP overheads būs mazāks kā visa FS figņa .

Tikt pie dumpa ? komoon, ja tiek pie dumpa tiek arī pie source backupiem un var īzī visu nojaukt :)

SQLs ir programmēšanas valodas, ja kas :) Virs > 1k ierakstiem tavs risinājums darbosies ātri cik Lembergs deklarē savus reālos īpāšumus. JOINus vēl kkā varētu realizēt (bet vai tas nav jāšifrē - kāda entīnija ar kādu attiecas ?).

Pamēģini php galā dekriptēt, nogrepopot un sasortēt 1k resultsetu .

Gadījumā ar SQL privilēģiju jūzeri ielauzties var tikai tad, ja atklāj mysql drošības bugu, kas ļauj iehavot roota privilēģijas ;). Pārējais ir bullshits.

Ar SQL injekcijām neko padarīt nevar, principā var jūzerim dot pieeju MySQL serverim pa tiešo un jams tur neko izownot nevarēs .

MySQL var izrubīt dajebkādu logošanu (kas gan būtu epic stupid and epic fail).

Principā man šķiet, ka pilsonis marrtins ir kaut ko salietojies un mēģina te episki tizlas sistēmas, kas nebūs drošākas par Mysql iebūvētas ACL jūzošanu.

Par hašošanu - visdrošāk ir saltu ģenerēt ar

http://www.php.net/manual/en/function.openssl-random-pseudo-bytes.php

MD5 der tikai novilktā porn integritātes nodrošināšanai, paroles hašo ar sha256 (PHP jamo supportē ar mhash extensiju).

skatoties uz capistrano, vismaz me ir radies iespaids, ka ja visu raksta railos, tad capistrano ir fucking īzī.

man nevelk ruby / rakefailus rakstīt mācīties, ja ruby kodēt nav plānots ;)

Brutālākais hostings "zem galda"

kristaps@1:~$ nslookup -q=A no.lv

 

Non-authoritative answer:

Name: no.lv

Address: 83.241.25.182

 

kristaps@1:~$ host 83.241.25.182

182.25.241.83.in-addr.arpa domain name pointer mpe-25-182.mpe.lv.

Meili : maģija . 2 Mx recordi resolvējas uz 1 ip .

kristaps@1:~$ dig mx no.lv

; <<>> DiG 9.4.2-P2 <<>> mx no.lv

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3409

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 2

;; QUESTION SECTION:

;no.lv. IN MX

;; ANSWER SECTION:

no.lv. 86392 IN MX 50 attisties.kopaa.ar.no.lv.

no.lv. 86392 IN MX 10 mail.no.lv.

;; AUTHORITY SECTION:

no.lv. 1665 IN NS ns5.no.lv.

no.lv. 1665 IN NS ns3.no.lv.

no.lv. 1665 IN NS ns2.no.lv.

no.lv. 1665 IN NS ns6.no.lv.

no.lv. 1665 IN NS ns.no.lv.

no.lv. 1665 IN NS ns4.no.lv.

;; ADDITIONAL SECTION:

mail.no.lv. 86392 IN A 83.241.25.212

attisties.kopaa.ar.no.lv. 86392 IN A 83.241.25.212

kristaps@1:~$ host 83.241.25.212

212.25.241.83.in-addr.arpa domain name pointer mpe-25-212.mpe.lv.

zona stāv pie kkādiem mailanyone.net

failu klient side kešošanu ar mod_expire nelien php kontekstā.

jāatmin, ka failus kešojot, failu nosaukumā jāiekļauj versijas numurs, piem img-r12.gif, lai updeitojot versijas klientiem viss rādītos smuki .

Jaut: kas ir image/css ? Kādēļ JS neliec kešot klientam ? Kādēļ eTagus nelieo? tas būtu vienkāršāk.

P.S. eTag ir verķis, kas ļauj browserim / serverim vienoties par to, ka klientam kešā ir riktīgais fails .

jāāā, vēl katrai kolonnai piekabināt sha čeksummu, lai pārliecinātos, ka nekas nav mainīts ! </sarcasm>

piegājiens tik pat gudrs kā prezervatīva vietā izmantot ūdens spaini.

gribi securot datu pārraidi uz remote mysql serveri ? MySQL supportē SSL konekcijas - būs vienkāršāk, ātrāk.

pasākums ir lēns.

gribi fiziski datus aizsargāt - glabā mysql datu failus kriptētā partīcijā / securo backupus.

jautājums - kā tu domā saglabāt konekcijas persistenci bez mysql user / pass glabāšanas sesijā vai cepumos ? PHP ir stateless verķis, aplikācijas uzlaušanas gadījumā būs elementāri nosniffot šo te pašu paroli un useri.

no sql injekcijām pasargās parametrizētu vaicājumu lietošana.

Datus normāli searchot nevar, nebūvējot papildus indeksu ar dekriptētiem datiem. (ar dekriptēšanu sanāks exact search, tas pats attiecas uz kārtošanu un grupēšanu). IMO, MySQL neļāva būvēt indeksus balstoties uz funkcijas rezultātu, jebkurā gadījumā šajā indeksā būtu atrodami dati.

Kverijos rādīsies šifrēšanas kejs. Jamo varēs nosniffot tīklā / atrast kveriju / lēno kveriju logā / binlogā

Vienkāršāks variants būtu taisīt logošanos aplikācijā ar MySQL jūzeri, uzbūvēt abstrakcijas slāni, kas ļauj jūzerim piekļūt tikai pie saviem datiem un ar piekļuves tiesībām nodrošināt, ka lietotājs šo abstrakcijas slāni nevar apiet.

Ja dikti vajag kaut ko kriptēt, es izvēlētos PGP + kādu XML datubāzi, kuru arī varētu šifrēt.

mod_deflate ir apache modulis .

.htaccess

AddOutputFilterByType DEFLATE text/html text/plain text/xml 

Kompresēs html, tekstu, xmlu. Principā common use case ar šito vajadzētu pietikt.

mod_deflate ir sakarīgāks variants par php zlibu, saspiež arī ne-ar-php servētos failus .

mod_deflate kompresē uz klientu sūtāmos datus (ja klients requestā pasaka, ka saprot kompresiju), tādejādi vairāk noslogojot CPU, bet samazinot datu pārraides laiku pa tīklu. Jāatzīmē, ka jau kompresētus datus kā jpegu, arhīvus utt., vēlreiz kompresēt nav jēgas, ja pat ir ieguvums, jams ir neadekvāts patērētajiem resursiem . Labi kompresējas teksts (ala htmls).

esmu aizgājis no ORM ceļu, kas manas kveriju palagu saīsināšanas prbl pilnīgi apmierina.

imo, vienkāršāk ir selectot no skata, updeitot to pašu skatu vai tabulu, tādejādi iegūstot gan vienkāršību, gan fleksibilitāti.

Lietas ir jātaisa vienkārši, bet ne pārāk vienkārši. Bieži vien visas abstrakcijas slāņi liedz fleksibilitāti un un pārkāpj DRY principu .

CFengine izskatās uber hardcore, bet pārāk uber priekš manis :)

phpDoc API dokumentāciju es nebuildoju, tam vajadzētu salabot savus docbook komentus, kam esmu pa slinku :>

phpUnderControl izskatās arī parāk samudrīts.

Lasu par Vlad The Deployer - http://hitsquad.rubyforge.org/vlad/ . Izskatās vienkāršāks un man sakarīgs, tikai arī ruby verķis

Principā man pie Capistrano / Vlad atbaida mana ruby/railu skilla trūkums un nevēlēšanās dēļ viena verķa šitā iespringt.

Delfins,

Ja verķi aizpūst uz serveri ir 4 komandas un nedod dievs serveri ir vairāki, tad pie sīka patcha tas aizņem neadekvāti daudz laika.

par autorizēšanu failiem - imo, vienkāršāk būtu rakstīt FastCGI autentifikatoru, nevis apache moduli . Risinājums arī būtu portabls starp web serveriem .

par pieejamību no citām sistēmām - kaut vai SSO ar kaut kādu citā valodā rakstītu app .

Sesiju glabāšana DB ir lēnāks un sarežģītāks risinājums, bet memcached prbl ir tā, ka tur dati persistence nav garantēta.

Ar DB access controli ir iespējams izveidot smalkāku drošības risinājumu, vienkāršāk nodalot dažādu aplikācijas moduļu pieejas līmeņus.

Par enkodēšanu - ir pythonā verķis, kas ļauj darboties ar php sesiju datiem serializētajā formā. Daudzvalodu/daudzaplikāciju serializēšanas algoritms limitē to, ko var bāzt sesijā - visādi objekti un sarežģītākas struktūras būs jādublē. Ja ir vajadzība šeirot tikai daļu, vienkāršāk ir pie __sleep un __wakeup iebāzt papildus maģisku serializēšanas algoritmu .

Aleksejam ir kaut kādu procedūru slimība. Oraclists bļins.

var elementāri nograntot jūzerim select / insert / update / delete tiesības tabulai.

Vajag atļaut redzēt tikai datu subsetu - uztaisam skatu, grantojam select uz skatu.

Vienkāršāk un pārskatāmāk, kaut gan nav tik ENTERPRISE (Lieki abstrakcijas līmeņi tur, kur jamie nah vajadzīgi).

Mazliet ir apnicis mūžīgais cikls -> unit testi -> svn ci -> ssh server -> svn update -> db izmaiņas -> restartēt fastcgi/apache.

Cenšos šito visu automatizēt, pašam kaut kā nevelk rakstīt visu laiku scriptus, tā nu lasu par Capistrano.

Kāds jamo lietot php / python appu deplojošanai uz serveriem ? Cik es lasu dokumentāciju, diezgan daudz Railismi lien ārā, kaut gan neredzu ideoloģiskus šķēršļus tūļa lietošanai arī manā gadījumā.

Atsauksmes, ieteikumi, komentāri, gotchas, common pitfalls ?

Pirmkāŗt, zināma prbl. šajā gadījumā ir linux distru pačotā source, piem ķeska ar Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/php5/+bug/316441

Rezumējot: expairējušās sesijas netiek dzēstas. Sanāk diezgan daudz kopā junk datu db.

Otrkārt, DB levelā privilēģijas bieži vien ir vieglāk enforcēt kā failsistēmas levelā.

Treškārt, DB var klasterēt, skeilot labāk nekā failsistēmu. Ja aplikācija ir deployota uz vairākiem serveriem, sesiju šeirošana ar FS ir PITA ar visiem NASiem/SANiem utt.

Ceturtkārt, ja vien nenotiek baisa nelaime, ja sesija pēkšņi pazūd, tad memcached ir labākais un ātrākais variants. (Skeilošana, HA utt).

Piektkārt, PHP bai default sesijas glabā failos, dīvaini serializētā formā (php.net/session_encode), php.ini norādītā dirā, kur faila nosaukums sakrīt ar sesijas id. Daži freimworki, piem. Horde un CodeIgniter ir izgudrojuši riteni no jauna un ir savs sesiju mehānisms, nevis PHP iebūvētais. Principā augstāk rakstītais varētu atbilst arī jamo implementācijām, kaut gan neesmu jamās iedziļinājies un neredzu iemeslu, kādēļ jamās ir rakstītas.

ja dikti gribi ar js, dinamiski uzģenerē JS, kas pieliek linkus DOM kokā. Paveras iespēja manipulēt ar GET parametriem un taisīt visādu maģiju.

Tā, lai strādātu uz visiem izplatītākajiem pārlūkiem, cross-domain ajax nav iespējams implementēt bez servera puses datu proksēšanas.

Ar uberskillu parasti projektē sistēmas un deleģē klavieres bakstīšanu baram code monkeyu .

Par pusstundu - normālu freimworku un libiem pa pusstundu var uztaisīt normālu mockupu .

Un normāla stundas likme ir tā, kuru ir ar mieru maksāt. Respektīvi - tas ir atkarīgs no veicamā darba sarežģītības, acu krāsas un citiem aspektiem .

No php var tikt klāt user-agentam tikai, kas apsolūti īzī nospoofojams un arī var netikt padots . :>

Tu visticamāk nepadod valīdu stringu ar sql vaicājumu, bet kkādu resursu .

Delīrija sesija, mļins.

PHP tauta ir diezgan slinka apgūt PDO un prepared statementus, kas eliminē SQL injekcijas pilnībā.

Tā vietā lietā archaisko mysql extensiju un izklaidējas ar manuālu datu eskeipošanu.

Taisi ar flaša socketiem, būs vienkāršāk .

Daži prokši padod HTTP_X_FORWARDED for, bet der atminēties, ka headeri var nospoofot klienta galā un jamam akli uzticēties nedrīkst. Ar anonīmo proksi nekas nesanāks, jamie tādus headerus nesūta.

Var čekot ip portus un skatīties, vai kkur nesēž proksis, kaut gan tas ir lēni un var nestrādāt.

Var arī likt cookijus un čekot pēc jamiem

Tabula ar foreign key`u uz jaunuma ID.

Aptuveni šitā

CREATE TABLE comments (
id int(10) unsigned not null auto_increment primary_key, 
post_id int(10) unsigned not null,
author varchar(20) not null, 
content text not null,
index(post_id),
foreign key post_id references posts(id))
engine = InnoDB;

komentāru atlase

SELECT id, author, content FROM comments WHERE post_id = :post

Vienkāršākais veids kā pārbaudīt vai izvēlētais vārds ir php iebūvētā funkcija / valodas konstrukcija ir ieklabināt php.net/{vaards} . Ja aizmet uz search page -> ir, ja neaizmet - nav.