ne valja ti pristup. ovde:
while($c=mysql_fetch_array($a)){

$id = $c["id"];
$user = $c["username"];
$pass = $c["password"];

}
u $user i $pass ce ti upisivati samo poslednjeg korisnika iz tabele.

promeni upit:

SELECT * FROM korisnici WHERE username = '$username' AND password = '$password'

tako ces dobijati samo tog jednog korisnika koji je odredjen sa tim usernameom i tom sifrom.

Promijenio sam query. Sada me šalje na index stranicu. Kako ću sada na naslovnoj doći do usernamea tj do ID-a. Na početku sam stavio session_start(); ne kontam.. kako da dobijem id.. znam da cu otic WHERE id='$id' ali ne znam to '$id', stavio sam tamo $_SESSION["user_id"] = $id; ali kada upisem echo $id nista.. (kad upisem u index.php) a u logiraj.php se nalazi to $_SESSION... Hvala.

zju... morao sam dva puta da procitam...

oces na index.php da dobijes $id koji je upisan u SESSION? peace of cake:

na index.php prva linija:

session_start();

posle gde ti treba:

$user_id = $_SESSION['user_id'];

pod uslovom da si u login.php skriptu upisao u $_SESSION['user_id']

zop :)

dodatak: i meni je trebalo vremena da skontam kako rade sesije. dok ne skontas, zna biti zbunjujuce. uglavnom, ako na jednoj strani, prvoj, recimo login.php pokrenes sesiju sa session_start() pa posle, recimo redirekcijom odes na index.php, ako ponovo kazes session_start() ne pokrece novu sesiju, nego nastavlja onu sesiju koju si poceo na login.php. tako ono sto si upisao u login.php u $_SESSION ti je dostupno na index.php isto u $_SESSION. nastavljanje sesija sa session_start() (najcesce) vazi sve dok ne ugasis browser (ili sam u programu unistis sesiju).

dodatak dodatku: vidi ovde za vise o sesijama: http://www.php.net/manual/en/ref.session.php

E super! Buljim dva sata u kod, a ne mogu da skontam sta je greska, samo sad mi se javlja nesto sto se do sad nikad nije javilo:


Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0

Hvala ti puno..

Edit: Dva put imao $_SESSION u kodu.. riješeno

daj kazi sta je bilo tacno, jos nisam video takvo upozorenje :o cackam po localhostu, al nikako da dobijem takav vorning :)

Hehe, pa bilo ono $_SESSION dva puta u kodu, konkretno:

$user_id = $_SESSION['user_id'];

I dole negdje:

$_SESSION['user_id'] = $id;

Jedno pitanje, sto se tice ovog Query-ja ... da li je bolje raditi:

SELECT * FROM korisnici WHERE username = '$username'

pa onda proveravati uneti password sa onim koji si izvukao iz baze, ili:

SELECT * FROM korisnici WHERE username = '$username' AND password = '$password'

i onda samo proveriti da li je broj vracenih linija razlicit od nule?

SELECT * FROM korisnici WHERE username = '$username' AND password = '$password' je bolje. odma uzimas tacno taj red, nemas jos jednu proveru. i proveravas na jedan red, ne na vise od nule.

Istina da je to onda jedna provera manje, ali kako znati da li je korisnik uneo neispravan password ili nepostojeci username?
Odnosno kako informisati korisnika tacno zasto je login odbijen?

Ja ipak vise volim

jer onda izvalcim tacno jedan podatak koji posle proverim. Zasto ljudi vole da izvuku sve (*) ako im nije neophodno, nije mi jasno, samo se puni memorija i opterecuje baza da vraca vise podataka.
Na ovaj nacin mozes i da mu kazes sta nije dobro (mada je iz sigurnosnih razloga bolje da mu kazes da ili jedno ili drugo nije dobro, jer moze na osnovu ispravnog username-a da pogadja password), tako sto ako nemas redova - onda nije dobar username, nema toga u bazi, a ako ima a ne slazu se passwordi- onda nije dobar password. Prosta logika.

Hvala na informacijama - kao sto sam i predpostavio, i jedan i drugi metod je zastupljen medju grupom :)

Da ne bi zapocinjao novu temu,ja takodje imam jedan problem oko logina moja skripta glasi ovako:

<form action="login.php" method="post" name="frm">
<table cellspacing="4" cellpadding="4" style="border-bottom-width: thin; border-left-width: thin; border-right-width: thin; border-top-width: thin; border-style: dotted; border-color: red;">
<tr>
<td>username</td>
<td><input type="text" name="formlogin" class="cssborder"></td>
</tr>
<tr>
<td>password</td>
<td><input type="password" name="formpass" class="cssborder"></td>
</tr>
</table>
<br> <input type="submit" value="login" class="cssborder">
</form>

<?php
if ($formpass == $pass && $formlogin == $username) {
session_register("loggedin");
$loggedin = "1";
//javascript-a za redirect to admin page.
?>
<script language="javascript">

location.replace("admin");

</script>

<h4><a href='admin'>you are now logged in, continue to the admin section</a></h4>
<?php
}
?>

Meni je jako sumljiv ovaj deo
if ($formpass == $pass && $formlogin == $username)
{
session_register("loggedin");
$loggedin = "1";

Inace pravim sebi Content manager pa iz vise skripta pravim sebi najbolju...

Znali neko sta je problem?

Samo dve usputne napomene.

Kao prvo nadam se da je poznato da su direktni upiti tipa

visoko podložni SQL injekciji i da je pre bilo kakvog izvršavanja dotičnog upita potrebno iskoristiti primera radi mysql_real_escape_string funkciju nad svim vrednostima koje dolaze direktno iz forme. Naravno pre toga je potrebno proveriti da li je uključen magic_quotes sistem i pre toga očistiti prosleđene vrednosti od escape-ovanih karaktera. Krajnji odbrambeni mehanizam je addslashes(). Sve navedeno otpada u slučaju korišćenja skladištenih procedura (stored procedures) koje mogu da se koriste u verziji 5 MySQL-a.

Druga stvar. Lično kod provere legitimnosti unetih podataka korisnika u login formi koristim metod

iz jednostavnog razloga što je iz sigurnosnih razloga preporučljivo u svim situacijama kada postoji više kriterijuma za ocenu ispravnosti nekog podatka iskoristiti što je moguće više dostupnih uslovljavanja. Primera radi u upitu

potencijalnom napadaču je ostavljeno dosta mesta za manevrisanje jer upit bez ikakvih pitanja vraća lozinku za svako uspešno pogođeno korisničko ime.

Zaštita sa proverom korisničkog imena i lozinke je utoliko sigurnija ako se koriste skladištene procedure.

Usput... Nikada ne treba obelodanjivati korisniku šta tačno nije u redu kod podataka koji su korišćeni u login formi. U tim slučajevima treba biti maksimalno nekooperativan i obavestiti korisnika da je logovanje neuspešno ili zbog korisničkog imena i/ili zbog lozinke ili čak samo da je login neuspešan :)

@Tesla
U svom kodu imaš dosta konceptualnih grešaka.
Kao prvo ako si imao nameru da proveru ispravnosti podataka izvršiš u istom dokumentu gde ti se nalazi forma (stranica sa formom poziva samu sebe) onda si trebao redirekciju da izvršiš direktno iz PHP-a a ne putem Javascripta. To znači da bi nakon slanje forme odmah na početku fajla trebao da imaš deo koji proverava ispravnost forme i koji će putem funkcije header() da preusmeri tok izvršavanja na stranicu koja bi sadržala poruku o uspešnom logovanju. Ako bi kojim slučajem podaci bili neispravni onda bi taj deo sa redirekcijom jednostavno bio preskočen a ti bi mogao lepo u formi da naznačiš delove koji nisu ispravni.

Sledeća stavka je da se tvoj kod oslanja na činjenicu da je na serveru na kome se izvršava fajl register_globals uključen tj. da su dozvoljene globalne promenjljive. Šanse da je to slučaj sa nekim novijim serverom su otprilike ravne nuli :) Umesto globalnih promenjljivih treba da koristiš superpromenjljive $_POST, $_GET, $_SESSION, $_COOKIE... Razlog za ovo je potencijalni rizik po sigurnost aplikacije.

Usput... session_register() je zastarela funckija koja se više skoro i ne koristi. Umesto nje preporučuje se direktno deklarisanje promenjljive putem $_SESSION-a i inicijalizacija na neku početnu vrednost.

Generalna koncepcija tvog koda bi trebala da izgleda ovako:

Ovo je samo generalna koncepcija.

I za kraj... Izraz

je ispravan jer operacija komparacije == ima prednost nad operacijom logičko ILI & ali je uvek dobra paksa delove odvajati dodatnim zagradama čak i kada to nije potrebno.
Evo primera radi jedne kompletne liste operatora koji se koriste u PHP-u sa njihovim prioritetom.
http://www.php.net/operators

<sub>[Ovu poruku je menjao holodoc1701 dana 02.02.2008. u 23:36 GMT+1]

[Ovu poruku je menjao holodoc1701 dana 02.02.2008. u 23:37 GMT+1]

[Ovu poruku je menjao holodoc1701 dana 02.02.2008. u 23:40 GMT+1]

[Ovu poruku je menjao holodoc1701 dana 02.02.2008. u 23:41 GMT+1]</sub>

@holodoc1701 hvala

Neznam bas najbolje php,naucio sam pomocu primera("naucio")mysql znam odlicno ali mi php bas neide u glavu ono znam osnovno ali opet.usvakom slucaju hvala,skontacu nesto sta dalje da radim...