Hej,
Som nu vet om man använder WWW-authenicate så får användaren upp en snygg dialog som kräver användarnamn i webbläsaren, då håller webbläsaren reda på login åt användaren och inga cookies behövs.
Men hur får man en webbläsare att logga ut på ett snyggt sätt, idag använder jag följande:
Men det innebär ju att webbläsaren står kvar på den sidan man klickade på ?section=logout
Användaren är ju urloggad och kan inte gå vidare på sidan utan att behöva autentisera sig igen, men användaren vill ju egentligen komma till en sida där det står "Du är urloggad".

Är det någon som har en bra lösning, tillexempel om man hade kunnat...
efter det att man skickat att användaren är "Unauthorized".
Men det går ju inte så bra.. Hur har du löst det?

Har letat runt på php.net men ger snart upp..

/N

Jag brukar lösa det med cookies. Iom det så behövs bara en länk...Logga ut ... programmet raderar cookien och skickar användaren till en sida, antingen framsidan eller "Du har nu loggats ur" ... ska inte vara så svårt att implementera detta i php..

Är du säker på att du inte kan välja själv hur en 401 Unauthorized sida ska se ut? Jag är väldigt säker på att man kan det även om jag inte kan minnas att jag testat.

Testa öppna utloggnings-sidan i en popup/osynlig frame och sedan låta main-framen gå vidare till hej-då-sidan efter att popupen/osynliga framen laddat klart.

jo det går väl. Men jag skulle föredra sessions/cookies, dialogen är förvisso snygg men funkar nog inte överallt och defenitivt inte alltid som du tror. Sen är det vanligare med on-page inloggning, så rent pedagogiskt är det en fördel.

Men även om du skickar dessa headers, är du inte fortfarande inloggad ända tills du stänger webbläsaren? Vad händer om du backar två steg? Har för mig att jusst detta var en av svagheterna med htaccess. Det går fint att logga in, men utloggningen var en svaghet. Inte 100%, men bäst att testa och att använda sig av session-cookies är nog vanligare än htaccess idag.

HTTP authentication är med i HTTP 1.0. Vilka webbläsare klarar inte av det?

HTTP authentication lider utav det problemet att man inte kan logga ut utan att behöva stänga fönstret.

Du kan annars testa med unset().

Man kan använda basic authentication och ha ett utloggningsförfarande. Men det kräver ändå cookies vid utloggningen.
Det man gör är att när användaren loggar ut sätter man en cookie som säger att han är utloggad.
På varje sida kontrolleras denna cookie och om den är satt så tar man bort den och returnerar 401 med en WWW-Authenticate header.

På så sätt kan man använda basic authentication (med tillhörande inloggningsruta) och ändå ha ett utloggningsförfarande.
Dock håller jag med om att det oiftast är mer lättanvänt att ha en inloggningssida, men i vissa fall är authentication via HTTP-protokollet trevligt.

Det där låter som en hemsk lösning. Istället för att se till att användaren är utloggad lurar du honom att tro detta. Det är ju bara att ta bort cookien för att den obehöriga ska få access. Ush och fy för fulhack.

Edit: Om han ändå ska använda cookies så kan han ju lika gärna låta cookien hålla i behörighetskoden. Går ju fint att kombinera med HTTP auth.

Håller med kullervo. Bättre att sätta cookie vid inloggningen och kolla ifall den är kvar och då behålla inloggningen.

Dock har jag ändå en förkärlek till sessions...

Okej, men om man nu har ett bra gäng användare som inte godtar cookies.
Dessutom slutar klienten skicka med användarnamn och lösenord (även vid föregående sida) om den en gång får ett 401.

Okej jag kan göra en egen sida för 401 meddelanden, men då måste användaren trycka på avbryt på inloggningssidan för att se sidan min 401 sida.

Tack för all input dock, får söka vidare =)

Det där låter konstigt. Har du verkligen testat följande?

det som är så bra med sessions är just att de INTE kräver cookies, man kan skicka med SESSID i request och det funkar lika bra! det ska finnas nån principiell nackdel med sessions, dock kommer jag inte på den nu...

Du kanske tänker att det går att "stjäla" någon annans session om man får reda på dennes SESSID? Om jag t.ex. skriver en länk på din sida till min sida, dina besökare följer den och jag kan då se SESSID i referer iom att den finns med i adressen... Men det går ju att skydda sig mot, förstås.

Jag sa inte at det var snyggt utan bara ett sätt att lösa det om man nu absolut vill använda sig av HTTP Auth och utloggning... <_<
Alternativen är mycket mer tilltalande tycker jag med, men det finns situationer då man inte kan välja helt fritt.
Det är ju dessutom möjligt att kontrollera att cookien verkligen blir satt och om den inte blivit satt - falla tillbaka på det sätt najk gör idag. Men visst om användaren inte stänger browsern och en elaking använder samma dator och raderar cookien kommer han att kunna logga in med den andra användaren. Detta är dock en risk man kanske är beredd att ta. Det handlar ju knappast om banktjänster och vad är sannolikheten att detta skulle ske? Och om browsern stängs så är det ej längre ett problem. Funktion och användarupplevelse måste vägas mot paranoia och paranoia är att föredra om man har möjlighet.