Hallo, schrieb schon diese Bemerkung und Frage andiese Frage früher, aber erst später bemerkt, dass es eine alte und "tote" Frage war. Da ich mir einige Erkenntnisse von anderen sehr wünschen würde, stelle ich sie als neue Frage.

Auf die Frage, wie man REST-konform authentifiziert, wird im Allgemeinen begeistert "HTTP-Authentifizierung" gerufen. Ich bezweifle jedoch, dass diese Leute jemals versucht haben, einen Browser zu erstellenAnwendung (anstelle eines Machine-to-Machine-Webservices) mit REST. (Keine Straftat beabsichtigt - ich glaube nur nicht, dass sie jemals mit den Komplikationen konfrontiert wurden.)

Probleme bei der Verwendung der HTTP-Authentifizierung für RESTful-Dienste, die HTML-Seiten zur Anzeige in einem Browser erzeugen, sind:

Der Benutzer erhält normalerweise eine hässliche, vom Browser erstellte Anmeldebox, die sehr benutzerfreundlich ist. Sie können keine Passwortabfrage, Hilfefelder usw. hinzufügen.Das Abmelden oder Anmelden unter einem anderen Namen stellt ein Problem dar. Browser senden weiterhin Authentifizierungsinformationen an die Site, bis Sie das Fenster schließenAuszeiten sind schwierig

Ein sehr aufschlussreicher Artikel, der diese Punkte Punkt für Punkt angeht, istHier, aber das ergibt aMenge von browserspezifischem Javascript-Hackery, Workarounds zu Workarounds usw. Als solches ist es auch nicht vorwärtskompatibel und erfordert daher eine ständige Wartung, sobald neue Browser veröffentlicht werden. Ich halte dieses saubere und klare Design nicht für sinnvoll und empfinde es als viel zusätzliche Arbeit und Mühe, nur damit ich meinen Freunden mein REST-Emblem mit Begeisterung zeigen kann.

Ich glaube, dass Cookies die Lösung sind. Aber warte, Kekse sind böse, nicht wahr? Nein, sie sind es nicht. Die Art und Weise, wie Cookies oft verwendet werden, ist böse. Ein Cookie selbst ist nur eine clientseitige Information, genau wie die HTTP-Authentifizierungsinformationen, die der Browser beim Browsen verfolgt. Und diese clientseitigen Informationen werden bei jeder Anforderung an den Server gesendet, genau wie die HTTP-Authentifizierungsinformationen. Der einzige begriffliche Unterschied besteht darin, dassInhalt von diesem Teil des clientseitigen Zustands kann durch die bestimmt werdenServer als Teil seiner Antwort.

Indem Sie Sitzungen mit den folgenden Regeln zu einer RESTful-Ressource machen:

A Session ordnet einen Schlüssel einer Benutzer-ID zu (und möglicherweise einen Zeitstempel für die letzte Aktion bei Zeitüberschreitungen)Wenn eineSession existiert, bedeutet dies, dass der Schlüssel gültig ist.Login bedeutet POSTing zu / Sessions, ein neuer Schlüssel wird als Cookie gesetztLogout bedeutet DELETEing / sessions / {key} (bei überladenem POST denken Sie daran, wir sind ein Browser und HTML 5 ist noch ein langer Weg)Zur Authentifizierung wird der Schlüssel bei jeder Anforderung als Cookie gesendet und überprüft, ob die Sitzung existiert und gültig ist

Der einzige Unterschied zur HTTP-Authentifizierung besteht nun darin, dass der Authentifizierungsschlüssel vom Server generiert und an den Client gesendet wird, der ihn weiterhin zurücksendet, anstatt dass der Client ihn anhand der eingegebenen Anmeldeinformationen berechnet.

Ich bin der Meinung, dass dies eine ausreichende Lösung ist, die einwandfrei funktioniert, aber ich muss zugeben, dass ich kein ausreichender Sicherheitsexperte bin, um potenzielle Lücken in diesem Schema zu identifizieren. Ich weiß nur, dass Hunderte von nicht-REST-fähigen Webanwendungen im Wesentlichen dasselbe verwenden Anmeldeprotokoll ($ _SESSION inphp, HttpSession in j2ee, etc). Der Inhalt des Cookie-Headers wird einfach verwendet, um eine serverseitige Ressource zu adressieren, genau wie eine Accept-Sprache für den Zugriff auf Übersetzungsressourcen usw. verwendet werden kann. Ich fühle, dass es dasselbe ist, aber vielleicht tun es andere nicht? Was denkt ihr Leute?