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.