HTTP 401 - Was ist ein geeigneter WWW-Authenticate-Header-Wert?

Question

Die Anwendung, an der ich gerade arbeite, hat einen Session-Timeout-Wert. Wenn der Benutzer nicht länger als diesen Wert interagiert hat, wird er aufgefordert, sich einzuloggen.

Alle Anforderungen werden über diesen Mechanismus weitergeleitet, der AJAX-Aufrufe enthält. Ursprünglich haben wir einen 200-Header mit der Anmeldeseite gesendet, was einige Probleme mit AJAX verursacht, da Code ausgeführt wird, wenn eine 200-Antwort gesendet wird, und die meisten Daten von diesen RPC-Aufrufen sind JSON- oder Raw-JavaScript, das ausgewertet wird (do not frage: |).

Ich habe vorgeschlagen, dass ein 401 ist besser, da unser JSON-Parser eine HTML-Anmeldeseite verbrauchen nicht versuchen, .. :)

Wenn reading the spec ich jedoch, dass das Feld WWW-Authenticate bemerkt muss auch gesendet werden.

Was ist ein guter Wert für dieses Feld? Wird Application Login ausreichen?

Answer 1

Wenn HTTP-Basic-Authentifizierung angibt, kehren wir so etwas wie:

WWW-Authenticate: Basic realm="myRealm" 

Während Basic ist die Regelung und der Rest ist sehr stark abhängig von dieser Regelung. In diesem Fall stellt der Realm dem Browser lediglich ein Literal zur Verfügung, das dem Benutzer angezeigt werden kann, wenn er nach der Benutzer-ID und dem Passwort fragt.

Sie verwenden offensichtlich nicht einfach aber da es keinen Sinn Sitzung Ablauf aufweist, ist, wenn Basis-Auth verwendet wird. Ich nehme an, dass Sie eine Form der formularbasierten Authentifizierung verwenden.

Von Erinnerung, Windows Challenge Response verwendet ein anderes Schema und andere Argumente.

Der Trick ist, dass es an den Browser ist zu bestimmen, welche Systeme unterstützt und wie sie darauf reagiert.

Mein Gefühl, wenn Sie formularbasierte Authentifizierung verwenden, ist es, bei der 200 + Relogin-Seite zu bleiben, aber einen benutzerdefinierten Header hinzuzufügen, den der Browser ignoriert, aber Ihr AJAX identifizieren kann.

Für ein wirklich gutes Benutzer + AJAX-Erlebnis, erhalten Sie das Skript, um an der AJAX-Anfrage zu hängen, die Sitzung abgelaufen gefunden, eine erneute Anmeldung Anfrage über ein Popup auslösen, und bei Erfolg, die ursprüngliche AJAX-Anfrage erneut und weitermachen wie normal.

den Cheat vermeiden, die gerade das Skript bekommt die Website alle 5 Minuten treffen die Sitzung am Leben Ursache zu halten, die den Punkt der Sitzung Ablauf besiegt gerade.

Die andere Alternative ist brennen die AJAX-Anfrage, aber das ist eine schlechte Benutzererfahrung.

Answer 2

Nein, Sie müssen die zu verwendende Authentifizierungsmethode (in der Regel "Basic") und den Authentifizierungsbereich angeben. Eine Beispielanforderung und eine Antwort finden Sie unter http://en.wikipedia.org/wiki/Basic_access_authentication.

Sie könnten auch RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication lesen möchten.

Answer 3

Wenn die Benutzersitzung abläuft, sende ich einen HTTP 204-Statuscode zurück. Beachten Sie, dass der Status HTTP 204 keinen Inhalt enthält.Auf der Client-Seite kann ich dies:

xhr.send(null); 
if (xhr.status == 204) 
    Reload(); 
else 
    dropdown.innerHTML = xhr.responseText; 

Hier ist die Reload() Funktion:

function Reload() { 
    var oForm = document.createElement("form"); 
    document.body.appendChild(oForm); 
    oForm.submit(); 
    }