Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  7 901
Jobber med en hjemmeside nå som bruker php (og som ikke er ferdig), og på denne hjemmesiden tenkte jeg at jeg skulle bruke $_SESSION['user_id'] som login-sjekk. Denne settes når man logger inn, og user_id er da bruker-id'n (logisk nok).
Deretter følgende for å sjekke om en bruker er logget inn:

Kode

if (isset($_SESSION['user_id'])) { /* ... */ }
Om da noen lager et script som vil gi $_SESSION['user_id'] en verdi på deres side, og de ikke lukker browser'n, og går inn på siden min, vil da login-sjekken feile?
Med feile mener jeg, vil siden tro at gjesten er logget inn siden $_SESSION['user_id'] har en verdi selvom den ble satt et annet sted? Logisk nok, vil jeg tro det funker slik, og om noen da har forslag for å unngå dette som ikke tar så altfor stor serverload med mange brukere.
En tanke jeg har, som burde være sikker nok, er følgende:

Kode

$login_check = mysql_query("SELECT user_id FROM users WHERE user_id = ".$_SESSION['user_id']." AND password = '".$_SESSION['password'])."'");
if (mysql_num_rows($login_check) == 1) { /* ... */ }
eller:

Kode

$login_check = mysql_query("SELECT user_id FROM users WHERE user_id = ".$_SESSION['user_id']." AND sId = '".session_id()."'");
if (mysql_num_rows($login_check) == 1) { /* ... */ }
Men om det virkelig er nødvendig å gjøre det slik, og måtte slenge inn øverst i hvert eneste dokument på siden? Tenkte jeg skulle belaste databasen minst mulig.

På forhånd takk for svar!
Session variabler blir vel (så vidt jeg har forstått) lagret og kontrollert på hver enkelt server. Det vil si at brukeren aldri vil ha direkte tilgang på de variablene og dermed skal de heller ikke følge med klienten fra et nettsted til et annet. Hvordan det er med flere sider på samme server vet jeg ikke, men regner med at det er sperret på en eller annen måte.

Edit:
Når det gjelder det at du kun sjekker om user_id er satt for å sjekke om brukeren har tilgang på siden eller ikke, tror jeg ikke det er den beste løsningen. Du må i det minste sjekke om variablen virkelig inneholder en ekte bruker id. Men hvis du skal ha litt mer sikkerhet ville jeg opprettet en egen database som registrerer ip, login, og en tilfeldig rekke tegn. Da kan du hindre at andre personer kan snappe om sessionen såfrem de ikke sitter på samme ip, du vil raskt kunne sjekke om brukeren virkelig finnes (sjekke login), og du kan bruke den tilfeldige tegn rekken som verdien i en session variable for å validere logginen. Høres i allefall ut som en god idee i teorien.
Sist endret av NoRemorse; 4. juli 2005 kl. 14:40.
improbable
Gusto's Avatar
DonorAdministrator
En session fungerer ikke fra aaa.com til bbb.com. Men en session som blir definert på et domene eller subdomene er gjeldende for hele det området. Det er trygt å bruke session som sjekk. Sessionen blir definert på serveren, ikke i nettleseren.
HaZnO's Avatar
Trådstarter
Ah, okey, flotters Det tenkte jeg ikke på, hehe. Takk for hurtig svar
*tilbake til kodinga*
Heisann, dette med autentisering av brukere er alltid et interessant spørsmål, og jeg tenkte jeg kunne bidra med hvordan jeg har løst dette.

Først og fremst kan jeg nevne at å lagre data i sessions regnes for å være trygt. Selvsagt kan serveren bli hacket og sessiondata hentet ut, men dette er ting som ligger utenfor ditt ansvar, og det eneste du kan gjøre er å sørge for å ha backups o.l skadebegrensende tiltak.

I resten av dette innlegget ligger det implisitt at brukeren allerede har logget inn med brukernavn og passord, f.eks. over en sikker SSL-linje, og jeg kommer derfor ikke til å diskutere den problemstillingen.

Nå, når det gjelder brukerautentisering, så er PHP litt knotete. Bruker man sessions, så har man på de fleste servere satt en default session lifetime som er umulig å overskride. Dette betyr at du selv ikke kan kontrollere (eller ikke kan regne med å kontrollere) f.eks. hvor lenge brukerene dine kan være innlogget (jeg tenker da øvre grenseverdier, de nedre er jo greie).

Edit: kan legge til at dette heller ikke er et trygt alternativ. Får man tak i en session id, så er det enkelt å utgi seg for å være en annen bruker.

Så, løsningen på dette er å bruke egne cookies for å lagre "state information". Du er da ikke begrenset av tid. Men dette impliserer et sikkerhetsproblem: det vil være vanskelig å lagre slik informasjon som ikke er enkel å få tak i for en tredjepart som så kan misbruke den.

En delvis løsning er å bare lagre informasjon som kan verifiseres for derettes å forandres dynamisk for hver sidevisning.

Dette betyr at du må ha ett felt for hver bruker i databasen hvor du kan lagre en såkalt "autentiseringsstreng", som gjerne bare en en tilfeldig kombinasjon av tegn (bokstaver og tall).

Når en bruker så logger inn, så genererer du en slik streng som du lagrer i databasen og i en cookie. Ved neste sidevisning matcher du strengen som brukeren sender mot den i databasen, og hvis den blir godkjent, så henter du ut userinfoen og lagrer den i f.eks. session variablene for enkel tilgang (det er her viktig at du IKKE gjenbruker session variabler, og at du ødelegger sessions og cookies når strengmatchingen feiler, eller så vil dette systemet være enkelt å omgå).

Når brukeren er autentisert så genererer du en ny autentiseringsstreng som du lagrer i den samme cookien og i databasen, dermed får brukeren en ny autentiseringsstreng for hver sidevisning. Dette er, sammenlignet med mange andre løsninger, en ganske hard og sikker løsning. Det er mye som skal "stemme" for hackeren for at han skal klare å omgå dette.

Her er et eksempel på SQL-kode som illustrerer hvordan jeg tenker:

Kode

// Brukeren sender autentiseringsstreng via cookie, og du henter ut eksisterende
// autentiseringsstreng fra databasen for å matche den mot det som brukeren sendte:
select * from user where binary authstr = 'O8k7X9v6T3n8Z6z8V2q2V7h7S1r8G7o8Q9o5Y4c7R6n6G5m1R1g5U6f5Q8j8Q9s3W3v8Q9'

// Autentiseringen gikk fint, og du erstatter cookien med en ny streng, og lagrer samtidig den nye strengen i databasen:
update user set authstr = 'H2e7C1j9N5t5P6c6R1f2A3r1X3z4S3u1M9t6A1o5O3b2W2t5G9s3F4h2S3n4P3l1H2s3G3v8N' where id = 999 limit 1
Sist endret av oracel; 9. juli 2005 kl. 00:59.
Var noe sånt jeg tenkte på i posten min også, men det var veldig deilig at en som virkelig har peiling fikk uttale seg.
HaZnO's Avatar
Trådstarter
Bra innlegg, menneh, nå er det ikke alle som har på cookies da
Pleier å legge til en $projectKey jeg da...

Kode

$pKey = md5( /* bør bygges opp av
client IP
prosjektnavn og en variabel til */ );
if( $_POST['a'] == 'Login' ){
$_SESSION[$pKey]['user_id'] == $row['userID'];
}
Sist endret av nudo; 11. juli 2005 kl. 11:38.