Rešenje mogu biti cookies ili neki drugi vid session tracking-a.
Ako je sigurnost bitan faktor, onda koristi SSL (https), sve ostalo je nedovoljno pouzdano.

OK, gde bih mogao da nadjem neki tutorijal o SSL-u? Takodje me interesuju i neki bolji sajtovi koji se bave ovom temom. Jel mozes da mi das linkove? Hvala.

Rešenje sa cookies je lakše za implementaciju ako ti je hitno, već se pričalo o tome na ovom forumu, pogledaj stare teme ima par linkova koje vredi pogledati. Ako u cookie staviš kriptovanu lozinku, dovoljno je sigurno za većinu stvari.

Korišćenje SSL-a je rešenje na nivou web servera, i to definitivno preporučujem za stvari gde je sigurnost kritičan faktor. SSL certifikat autentičnosti se plaća mada nije neophodan, možeš ga i sam generisati i komunikacija će biti jednako sigurna, samo će korisnici dobijati jedno upozorenje pri pristupanju sajtu. Originalne certifikate izdaje http://www.thawte.com/
Treba ti još i Apache web server sa ssl podrškom, konsultuj www.apache.org kao i http://httpd.apache.org/related_projects.html#apachessl

Takođe koristan link ako ćeš ti instalirati taj apache:
The Soothingly Seamless Setup of Apache, SSL, MySQL, and PHP
Za pristup stranicama ćeš koristiti port 443, dakle ili http://sajt.com:443/ ili https://sajt.com/

prosto se namece:

session_register ("logged_on");

naravno moze i preko cookies - ali to je primerenije perl-u, gde nema session varijabli (na zalost).

Sto su kolacici primereniji Perlu? Krajnje je jednostavno koristiti
kolacice i u PHP-u (a i bilo kom drugom jeziku).

Takodje, ko te lagao da nema session variabli u Perlu?? Pogledaj
Apache::Session modul, npr.

Ja koristim Apache::Session, npr, i jako je fina stvarcica.

Poz, alex.

nisu primereniji, nego su zaebaniji. lakse brate session variable, a?



"i tata bi, sine!" :)
kad zakonom propisu module koje je obavezno instalirati, mozemo da pricamo... do onda ne zelim da se neprijatno iznenadjujem sa svakim sledecim provajderom.
btw - instaliraj mi apache::session na activeperl i sagradicu ti bi(j)oskop...

Ma nisu zajebaniji, cini ti se. Meni se takav stil vise svidja od
automatskog registrovanja varijabli. Mada, peace of cake je
napisati funkciju koja ce da registruje variable od kolacica..



Eh, da znas - muke s Perl modulima su verovatno najveci "bad thing"
u Perlu - ponajvise sa verzijama. Oko toga bi dosta toga moglo da se
poboljsa. Ja recimo prilikom svake instalacije Linux masine (ili Perla
negde) uvek imam "svoj" set modula koje instaliram (koji ce mi ikada
biti potrebni).. Tako da nikad nemam problema, ali samo na svojim
masinama. Na drugim (tudjim) masinama, uvek je problem naterati
administratore da instaliraju module. Mada, mislim da bi svaki posteni
administrator trebalo da instalira at least DBI pakete (za pocetak).



Sto, zar je problem?? Pre svega, potreban je Apache da bi instalirao Apache::Session. Sad cu bas da probam da instaliram modul pa cu ti
javnuti.

poz, alex.

Pa mozes i pass u kukija da kriptujes sto ti je isto _dovoljno_ sigurno ...
ali ipak prvi put pass mora u plain text da ide kroz mrezu ...

naravno. kada radim cgi imam svoje funkcije koje registruju varijable od query i post stringa, i od cookies (svoje - zato sto se ne oslanjam na module i ne volim da mislim sta je koja budala instalirala na serveru). medjutim, i dalje postoji problem setovanja cookie-a koji mora da ide u header-u, a posto obicno napravis neki "univerzalni" deo stranice moras da se dodatno opterecujes promenljivima tipa "setovati cookie i koji"... definitivno, ipak je manji komfor?

drugo, mozda ipak treba misliti i na paranoike ili neuke kojima su cookies disabled. u tom slucaju jedino suvislo resenje je session i to sa kobajom u query string-u... (ovo vise na filozofskoj bazi; iskreno, uvek ih od*ebem :) )



eh da... radio sam u cgi-u poveliki shop koji je sticajem nesrecnih okolnosti trebalo da bude postavljen na iis platformu (sto generalno nije problem jer istu rabimo kao local test server u firmi), sa mssql bazom. kada je projekat bio vec gotov i uploadovan ispostavilo se, naravno, da nemaju ni "d" od dbi i dbd::odbc, nego koriste (krajnje retardirajuci) win32::odbc. ostav!, sto bi se reklo...



nema ga medju activestate-ovim modulima, a to je jedini meni poznat nacin instaliranja modula na activestateov perl (voleo bih da me neko demantuje, cak bih ga i vodio na pivo za tu kontrainformaciju).

thanx, anyway.

Ali koja je to sigurnost i ako se proba sa cookies? Prvi put saljem nekriptovan password, a svaki sledeci put kriptovan. U svakom slucaju, pass non stop siba kroz mrezu, gde neko ko monitorise mrezu lako moze da ga uhvati. Tako da ja ne vidim veliku vajdu od kolacica.

prvo, ako ti je stalo do zastite podataka, ceo "users" area je pod ssl-om (a to bar nije neka mudrost). dakle, sve ide kriptovano. dalje, svakako ces manju stetu napraviti ako umesto cookie-a sa pass-om jednostavno postavis cookie "logged_on" ili stagod...

Eventualno u cookies postavis username i zatim ga ponovo na svakoj strani koju zelis da zastitis autentifikujes kroz bazu. Ako neko stavis samo svic, dakle $isLogged ili tako nesto, onda rizikujes puno. Postavis i to i username pa onda lepo "pitas" da li je uopste covek logovan, pa ako jeste, radis ostatak. Ako nije, vracas ga nzad na login stranu. Toliko o tome...

Mada, session varijable su bolje resenje.

Administratoru foruma: ako vec text polja za pisanje postova moraju da budu siva, ne mogu li slova biti boldovana??? Please?? Pretty please???

absolutely - na to sam i mislio, dakle "isLogged" cookie postavljas samo umesto password-a, a username ostaje u cookie-u. moze malo i da se "obogati" predvidjanjem polja u users tabeli koje bi se zvalo npr. "last_login_time", pa poredis da li je vece od trenutnog-2 h, npr; time se nista ne gubi, osim sto se korisnici koji se "ne skidaju" sa sajta posalju na "rutinsku proveru" posle tog vremena.

dalje, jos jedna finesa za sprecavanje zloupotreba - prilikom promene sifre, ako je predvidjena, obavezno predvideti i field "old password".

"jure me neki paranoici" :)

Cekaj, bre, bre... :) Mozes i da postavis jednostavno cookie timeout, tj. da cookie istekne posle odredjenog vremena. Recimo, postavis da cookie istice posle 3-4 minuta. Na svakoj strani kada uspe autentifikacija, ti lepo produzis trajanje cookie-u za tih 3-4 minuta. I tako stalno.

I dalje mislim da su sessions pravilniji odgovor na ovako nesto, ali ako vi momci tvrdite da nisu... :)) Sala mala, naravno.

Idem da "programiram" u VS.NET-u...

jes, bogamu, imas pravo! (ovo za vremensi ogranicene cookies). majku mu bozju, ne pade mi na pamet... <- [palo bi, samo kad bi imalo sta da pogodi...] <- ignorisite ovu samokritiku!

ipak, kao sto rekoh (tamo negde gore, oduzio se thread...) - bolje session variable, slazem se. lakse je.

Naravno da je lakse. Pogotovo sto PHP ima onu foru sa trans_session_id...Znas o cemu pricam vec...Pa onda mozes lepo da radis. Za razliku od ASP-a koji mora da ima cookie na klijentovoj masini.

Ono sto me je zaista razocaralo kod ASP.NET-a jeste to sto on predefinisane nacine za autentifikaciju i ti mozes malko da se zezas, ali ne krucijalno...Ponekada pomislim da MS zaista zeli da svi programeri budu bezumna stoka...

znam, napisao sam i to negde gore... jedino nezgodno u svemu je sto postoji problem sa guranjem te "kobaje" u favourites...

hehe... no comment.

Ma ja imam comment za njih... :) Salim se, naravno. Iskreno, .NET za sada samo proucavam. Ako bude nekoih para odtoga, dobro i jest. Ako ne...pa, od perla ce uvek biti, zar ne?? :)

da li ste vi normalni ? da se stavlja username u cookie ?????????

pa korisnici mogu da spoofuju cookie, tj. da promene vrednost cookija, tako da monda mogu da pristupe nekom drugom nalogu recimo , i to bez lozinke!

Naravno da ne stavis samo username. Poena je da se stavi i jos nesto sto ce korisnika "odvojiti" od drugih. Recimo, neki ID ili tako nesto. Na kraju krajeva, ako bas hoces sigurnost, koristis i kriptovanje, MD5 ili DES. Ima mnogo tehnika za takve stvari...

Kako bi ti to uradio???

hmmmm
pa dobro recimo da napravi jedan cookie u koji stavis username i nalpravis drugi cooki u koji stavis neki random dugachak number... e sad kako, mislim ono kako da s eproverava taj random number ??? uh moram priznati da sam slab sa kukijima

uspori malo...
ako je potreban visok nivo sigurnosti, normalno je da ces dodati jos detalja - na primer, prilikom svakog logovanja dodas cookie sa nekim random id-em (nalik na session_id) koji istovremeno upises u bazu za tog korisnika. posto sve (u tom slucaju) ide preko ssl-a, male su sanse da ce neko da "pokupi" taj broj, a ti ga koristis umesto passworda... mada to nije toliko bitno jer ako koristis ssl mozes i password da mu stavis u cookie, na kraju krajeva...
s druge strane, pogledaj cookie koji ti je "zalepio" elitesecurity.org. jasno je - bezbednost nije esencijalna, pa je ustupila mesto komforu...

ja sam ga danas napravio sa md5 i ne diram vishe

Evo, ulećem i ja u diskusiju.

Palo mi je napamet da korisniku u cookie smestite dva podatka - njegov username i string koji sadrži krptovani (na samo vama znan način) username tog korisnika.
Znači, standardnom crypt funkcijom ili nekom vašom one-way crypt funkcijom.

Naravno. Ovo je idealno. Ili da svaki korisnik nema prost integer kao ID broj za njega, vec da ima ono sto SQL Server zove "unique ID" tj. string od 32 karaktera koji se nasumicno bira za svakog korisnika. Pa neka macam pogadja do prekosutra...

ja samnapravio da ovako:

jedan cookie -- username
drugi cookie --- cr_pass=md5 password
treci cookie --- random $temp_id

i onda u member.php poredi if isset($username) and $cr_pass== sa criptovanim passwordom iz baze and temp_id=tempid(iz baze). ako sve ovo prodje onda ga pusti,inache ne.

Moze i samo sa jednim jedinim kolacicem.

$sessionstr = $username . crypt($password) . microtime();
$cookiesession = md5($sessionstr);

Ovaj $cookiesession se smesta u bazu u polje session (or something) kad se korisnik uloguje, i kasnije se provera da li je ulogovan korisnik vrsi po tome.

Provera je krajnje jednostavna:

- proveri se da li postoji cookie, i ako ne postoji korisnik nije ulogovan..
- ako postoji, proveri se da li postoji korisnik sa istim session-om u bazi, ako ne postoji, znaci da nije autenticni cookie session
- ako postoji, korisnik iz rezultata provere u bazi je taj ulogovan korisnik.


Veoma efektivno - vec sam ovo predlozio Gojku da implementira u ES forum proveru. Ja ovakvu proveru koristim za skoro sve Web aplikacije koje radim, i verujem da ne postoji nacin da se prevari
ovakva provera.. Naravno, cookie je moguce prosiriti prilepljivanjem jos jednog microtime()-a na kraj stringa kriptovanog md5 funkcijom (cisto ako ste paranoik)..

Uz to, krajnje je jednostavno.

Poz, alex.

ovo gore sto sam napisao RADI, tako da......

Pazi, ima milion nacina. Ovaj sa bazom nije los, ali kako onda pravis "garbage collection", odnosno, kako radis brisanje iz baze??? Recimo, ako korisnik ode da jede sendvice i vrati se i uradi refresh?? Istekne cookie, to je OK, on se vraca nazad na stranu za logovanje, ali da li u tom trenutku se brise ono sto je u bazi ili ne??? :))

Sve ima svoje zasto... :)) I zato...

pri svakom logovanju se vrsi dodeljivanje novog temp_id , znachi overwriteuje ga

inache, stavis da cookie traje vechno i eto ti refresh.

hej a sta ce ti cookie sa pass-om (kriptovanim ili ne, whatever)
pretpostavka da ako je high security onda nema pamcenja sifre, tako da mi taj detaljcic izgleda kao cist visak... u protivnom (ako pamti sifru) visak je taj temp_id, posto nema logovanja, jel'.

pa sifru mora da pamti i sifra mora da se kriptuje


jer ako nema sifre u cookiju onda bi neko mogao da napravi cookie u kome ce biti username nechiji i takodje da napravi cookie u koji ce da stavi neki temp_id, sta znas mozda bas i pogodi temp_id .

a kriptovani pass je jos korak vise ka sigurnosti, znachi nema sansi da neko pogodi bas kako glasi kriptovani password, tako da......

Ali mozes temp_id da napravis u nekom fazonu, recimo da bude ec pomenuti random string od 32 karaktera, slova i brojevi, i da zatim kriptujes username i eto ti lepote... :))

hehhehhe... interesting.
dakle mogao bi da pogodi temp_id od npr. 30 brojeva (ili karaktera, whatever), lakse nego da "nabode" sifru od tipicno 5-10?!?!?

a i nesto oko tog nabadanja - cuveni problem malih verovatnoca:
"koja je verovatnoca da ce sto majmuna sa pisacim masinama napisati encyclopedia britannica?"

dajmo, ljudi, uozbiljimo se...

sifra je kriptovana....... a ko ce da pogodi kriptovanu sifru ??????!!!!!!!

pa dogovori se... jel' moze da pogodi ili ne?
kriptovanu sifru i temp_id mozes da posmatras kao jedno te isto...

temp_id je jedan devetocifreni broj ili tako nesto, znachi samo brojevi

a kriptovana sifra je nesto tipa xfdsigf8b789789hb7b7gf897897ngfngnbklgj45436

znachi sadrzi i slova i brojeve tako da je teze pogoditi kriptovanu sifru nego temp_id

pa *ebo ga otac, gluvonemi bi se bolje sporazumeli od nas dvojice...
ko ti, naime, definise taj "temp_id"? ko ti brani, da ga generises sam, u obliku i po algoritmu koji najbolje odgovara nivou paranoidnosti koji zelis da primenis? sto ne bi bio varchar(128)?

a, u principu, samo pokusavam da ti dokazem da je nesto od ta dva (temp_id ili password) suvisno u cookie-u. inace se slazemo u metodu. a i razvodnili smo topic do bola. da ga batalimo?

ajde