Login

Det bestemmer du jo helt selv.

Umiddelbart synes jeg det virker mærkeligt at du gemmer det krypterede (jeg håber i øvrigt du mener hashede) kodeord i brugerens session - hvad skal du bruge det til?

Personligt kontrollerer jeg blot om der er et user id og ved hvert sidekald kontrollerer jeg om brugeren stadig er aktiv/har ret til at være der hvor han her.

Du gemmer vel de roller brugeren har og for en given side checker du om brugeren har en af de roller som giver adgang.

#2 Jeg kontrollerer dem faktisk for hvert request. Jeg har tidligere oplevet at have ophævet alle rettigheder for en bruger, hvor rollerne var gemt i sessionen - det betød at indtil brugeren var logget ud, kunne han fortsætte med sin 'ballade' som jeg forsøgte at stoppe ham i.

Resultatet blev at jeg purgede alle sessions for at få ham stoppet.

Umiddelbart synes jeg det virker mærkeligt at du gemmer det krypterede (jeg håber i øvrigt du mener hashede) kodeord i brugerens session - hvad skal du bruge det til?
- Det var kun såfremt det ikke var nok at se om sessionen findes. Hvis man på hver side skal lave et tjek på om en session også matcher brugernavn og password i databasen, skal man jo have det.

Betyder det med andre ord at det er nok at tjekke f.eks. sådan her:
if (!isset($_SESSION["navn"])) {
  header("Location: sted");
}
For at sikre om en bruger er logget ind.

Det er ikke muligt for en bruger at lave eller manipullere sessions?

sessions gemmes server side ikke client side

Forstår jeg det dermed rigtig, at det så er nok blot at tjekke ligesom i eksemplet ovenover?

Hvis den session du kontrollerer op imod kun er sat hvis man er logget ind, så i princippet, ja.

Hvorfor "i princippet"?

Vil du/I gøre det på en anden måde?

mik2000: Du bør jo nok lave noget, hvor du - som også lidt foreslås - tjekker op på det i databasen i hvert fald i et eller andet omfang. Det kan være tungt at gøre hele tiden, men du kunne jo fx gøre sådan, at du satte en session med brugeres ID og en session time. Denne session time blev opdateret hver 300. sekund, og kun samtidig med at den session time blev opdateret, tjekkede du i databasen, om der var sket noget nyt med hans rettigheder.

Jovist, du giver brugeren 300 sekunder til at lave de ting, han ikke vil, men det er i hvert fald én måde at gøre det på.

Jeg vil dog foreslå, at du forsøger at lave et check på en eller anden måde, der tjekker, om der findes en bruger med ID = X, RETTIGHED1 = Y1, RETTIGHED2 = Y2. Og så laver du bare et count. Er der 0 brugere, jamen så har han ikke (længere) rettigheder.

Det kan bygges på rigtig mange måder alt efter hvordan du i dit framework håndterer brugere, men ovenstående var i hvert fald hhv. én løsning på, hvordan du kunne undgå så mange DB-kald og én løsning på, hvordan du kan undgå misbrug, når du har redigeret en brugers rettigheder.

God dag.

Medmindre man har nogle meget specielle krav om at kunne aendre privs on the fly, saa vil bare lade privs ved login gaelde.

Folk der faar flere privs maa logged ud og logge ind igen for at aktivere.

Folk der faar faerre privs maa enten bare goere sig faerdig eller smides af systemet, saa de er noedt til at logge ind igen.

Lukker
Smid et svar hvis I ønsker point ellers gives point til dette svar :)

Jeg fik det nogenlunde løst, men blev ikke helt klog på det.

tjo

Ps. hvis du skulle vide hvordan man henter menu fra database og udskriver i ul li, så må du meget gerne hjælpe med:
http://www.eksperten.dk/spm/991108

Skulle repox ikke have haft?

Jo det har du ret i. Ser lige om han vender tilbage, og så kan jeg se om man kan fortryde - ellers kan han evt. få i en ny tråd :)

Jeg kan ogsaa oprette et spm. med halvdelen til ham.

Hej

Nej du har hjulpet mig så meget gennem tiden, så det gør jeg hvis han skriver :). Men tak for det :)