Iskreno, mislim da ovaj prvi nacin nikad nisam video da neko koristi.
Da, bezbedno je ovako cuvati sifre, dokle god apache ne "prsne".

Pa prednost koristeja mysqli ekstenzije je sto ima proceduralni i OO interfejs, tj. sintaksu - ko sta vise voli to i koristi! Mnogi navode da je brža i sigurnija od 'stare' mysql ekstenzije.

I kod drugog nacina, treba izbjegavati mysql_result() funkciju, ako se 'vracaju ogormni rezultati' - tada je bolje korstiti neku od 'fetch' funkcija, jer su mnogo brže od mysql_result().

Ne bih baš rekao . Bezbedno je ako imaš dedicated server ili VPS. Na shared serverima, postoji mogućnost da ostali korisnici servera mogu da pročitaju i tvoje fajlove, pogotovo ako korisnici imaju SSH pristup. Čak može da se napiše jednostavna PHP skripta koja će da "čita" tuđe fajlove. Ili, perl skripta ako PHP ima neka ograničenja (safe mode, openbase dir, itd..). Naravno, sve ove komplikacije mogu da se izbegnu ako admin servera lepo podese sve dozvole, i običnih korisnika i http servera.
Ako pogledata modove vaših fajlova na (linux) serveru, videćete da skoro svi fajlovi imaju mod 644, a ova boldovana četvorka znači da bilo ko može da čita vaše fajlove (naravno, ako ima pristup serveru, a to može da bude na više načina, kako onih legalnih, tako i ilegalnih).

p0z

Slazem se da moze da im pristupi, mada treba dosta srece pogadjati putanju fajla, naziv promenjivih itd... Kako cuvati onda cuvati te parametre?

Eto ja sam tako i poceo da ucim sa mysqli... tako sam i navikao... ovo i na kraju i znaci improved... verovatno i jeste to bolje... ali eto kao sto sam i rekao kod nekih hosting provajdera se tako ne moze raditi... moraju ove starije metode da se koriste. Verovatno imaju neki MySQL 3.x ili 4.x. Kad budem trazio neki hosting sledeci put obavezno moram pitati da li podrzavaju tu mysqli metodu.

Nauci covek ponesto svaki dan ;)
Mada, gotovo uvek koristim adodb lite, ali za neke sitne stvarcice, koristim stari, prvi metod.
Koji je okvirno procenat hostinga koji (ne)podrzavaju ovu metodu i koje su joj (prakticne) prednosti u odnosu na staru metodu i eventualno u odnosu na adodb?
P.S. Sve vreme sam povezivao ovo sa sql lite, ne znam zasto :))

Svi kojima je php 4.x default (ili jedina) verzija ne podrzavaju ovo.
Takodje, mislim da je mali broj i onih koji furaju verziju 5 a imaju ovo obavezno ukljuceno. Mada mislim da ce polako da se ukljucuje...

Pa i ne mora da se pogađa. Pomoću komandi kao što su ls, find, cat... mogu se pronaći i pogledati ti fajlovi. Pogledaj PHP shell-ove kao što su c99 ili r57 i iznenadićeš se kada budeš video šta oni sve mogu. Zato je (PHP) Include Vulnerability (Remote ili Local) vrlo neprijatna stvar. (Local zato što se može ubaciti PHP kôd u .jpg, .gif, .png... fajl, i ako taj sajt ima forum sa mogućnošću upload-a avatra, onda PHP kôd "završava" na serveru i čeka da bude include-ovan )

Kako se zaštiti... Može se zatražiti od admina servera da ubaci konstante (i dodeli im potrebne vrednosti) u podešavanja web servera (apache).
I onda bi ti u svojim .php skriptama koristio ovo:


Ima tu još dosta priče, ali da ne dužim previše..

p0z

Cek, cek... Mozda odosmo sa teme u bezbednost, ali ako uspe da pristupi fajlovima, pomocu ovih "malicioznih" kodova, dal bi onda mogao da pristupi i konstantama DB_SERVER, DB_USER, DB_PASSWORD ? Mislim, ako ja iz mojih fajlova, mogu da im pristupim, a neko inkluduje moj fajl, onda bi trebalo da moze i on da im pristupi (ili ne :( ) ?
Imas li neki koristan link (iz prve ruke) na ovu temu?

Pogledaj PM..

Može da im pristupi i može da ih echouje

http://phpsec.org/projects/guide/sr/5.html
Pri dnu:

Ne znam više ni ja šta je bezbedno a šta ne.. U svakom slučaju, ja imam privatni hosting (kako kaže ova rečenica) koji sam administriram, tako da nemam problema da mi neko gleda .php fajlove

p0z

Sve što je potrebno PHP skriptu da bi radio (varijable, konstante, spoljne datoteke/resursi, $_ENV, ...) može i da se ehuje.
Nema pouzdanog načina kako zaštiti lozinke u skriptovima.

Najbolje što sam do sada video je kodirati lozinku negde u skripti (ili u *.ini) a skript gde je funkcija dekodiranja je zajedno sa uspostavljanjem konekcije na DB i autentifikacijom korisnika (iz kukija/sesija), kodiran nekim boljim koderom (zendencoder,ioncube,...).

To mu na kraju dodje, da je na shared hostingu, najsigurniji "moguci" nacin cuvati ih regularno u php fajlu, pa APP (Ako Prodje-Prodje). Osim ako hosting ne daje neke od gore navedenih mogucnosti.



Da, al u konkretnom slucaju mu ovo dodje princip "Kljuc je u konzervi" jer mora da se pristupi bazi da bi se izvukli parametri za konekciju na bazu

A koliko je "opasno" nezatvoriti bazu... mysql_close($baza);....

Pa teoretski, server (ili beshe php) je sam zatvori...
Iskreno, ja se ne secam da sam ikada (namerno) zatvorio konekciju i niko se do sada nije zalio
Interesanto pitanje, moracu da potrazim misljenja struchnijih...

bolje zatvaraj, jer moze da se desi da otvoris veliki broj konekcija, i da tako mysql dodje do limita u broju konekcija, i posle toga, vise niko ne moze se zakaci za njega. Na shared hostingu to pogotovo moze da se desi.

E to mi se chesto desavalo na loopiji, a uvek me mrzelo da gledam zasto
Ali definitivno nije do moje aplikacije
A kako ide sa persistent konekcijama i bez njih? jel moze onda da dodje do zagushenja konekcija?

hehe, moze i sa njima, i to veoma lako. ONe se tek ni malo ne preporucuju na shared hostinzima. Jer svaka skripta pokrene svoju konekciju a ne zatvori je :) , i ako imas malo poseceniji sajt sa malo vise php skripti koje pozivaju bazu , eto belaja.

@flylord
Da li je moguce da se skripta izvrsi a da konekcija ka bazi ostane otvorena?

Malo pre mi je receno, kad sam zvao jedan hosting provajder, da oni imaju ukljucenu ovu mysqli metodu, a imaju php4...
Da li je to moguce? Meni se cini da sam negde procitao da je samo php5 podrzava kao i da tek od php5 pocinje OOP.

Znaci interesujeme dali ovaj metod broj 1 koji sam naveo mogu da koristim pod php4?

Hoces ja da ti kazem da pogledas u manual ili ces sam to da uradis?
OOP pocinje pre php5.