Verstoßen Sitzungen wirklich gegen RESTfulness?

Question

Ist die Verwendung von Sitzungen in einer RESTful-API wirklich ein Verstoß gegen RESTfulness? Ich habe viele Meinungen gesehen, die in beide Richtungen gehen, aber ich bin nicht überzeugt, dass Sitzungen RESTless . Von meinem Standpunkt aus gesehen:

• Authentifizierung ist für RESTfulness nicht verboten (sonst gäbe es wenig Nutzen für RESTful-Dienste)
• Die Authentifizierung erfolgt durch das Senden eines Authentifizierungs-Tokens in der Anfrage, normalerweise in der Kopfzeile
• dieses Authentifizierungs-Token muss auf irgendeine Weise beschafft werden und kann widerrufen werden; in diesem Fall muss es erneuert werden
• das Authentifizierungstoken muss vom Server validiert werden (sonst wäre es keine Authentifizierung)

Wie können Sitzungen dagegen verstoßen?

• client-seitig, Sitzungen werden mit Cookies realisiert
• Cookies sind einfach ein zusätzlicher HTTP-Header
• ein Session-Cookie kann jederzeit abgerufen und widerrufen werden
• Sitzungscookies können bei Bedarf eine unbegrenzte Lebensdauer haben.
• die Sitzungs-ID (Authentifizierungs-Token) wird serverseitig validiert

Für den Client ist ein Sitzungscookie also genau dasselbe wie jeder andere HTTP-Header-basierte Authentifizierungsmechanismus, außer dass er die Cookie Kopf Kopf Kopf Kopf Kopf an statt der Authorization oder eine andere proprietäre Kopfzeile. Warum sollte es einen Unterschied machen, wenn dem Cookie-Wert serverseitig keine Sitzung zugeordnet ist? Die serverseitige Implementierung braucht den Client nicht zu betreffen, solange der Server verhält sich RESTful. Daher sollten Cookies allein eine API nicht zu einer RESTless und Sitzungen sind einfach Cookies für den Client.

Sind meine Annahmen falsch? Was macht Sitzungscookies RESTless ?

Answer 1

Die HTTP-Transaktion, die Basiszugriffsauthentifizierung, ist für RBAC nicht geeignet, da die Basiszugriffsauthentifizierung jedes Mal den verschlüsselten Benutzernamen und das Passwort zur Identifizierung verwendet, während bei RBAC die Rolle benötigt wird, die der Benutzer für einen bestimmten Aufruf verwenden möchte. RBAC prüft die Berechtigungen nicht anhand des Benutzernamens, sondern anhand der Rollen.

Man könnte eine Verkettung wie folgt vornehmen: BenutzernameRolle:Kennwort, aber das ist eine schlechte Praxis und außerdem ineffizient, denn wenn ein Benutzer mehrere Rollen hat, müsste die Authentifizierungsmaschine alle Rollen in der Verkettung testen, und das bei jedem Aufruf erneut. Dies würde einen der größten technischen Vorteile von RBAC zerstören, nämlich einen sehr schnellen Autorisierungstest.

Dieses Problem lässt sich also nicht mit einer einfachen Zugangsauthentifizierung lösen.

Um dieses Problem zu lösen, ist die Aufrechterhaltung von Sitzungen erforderlich, was einigen Antworten zufolge im Widerspruch zu REST zu stehen scheint.

Das ist es, was mir an der Antwort gefällt, dass REST nicht als Religion behandelt werden sollte. In komplexen Geschäftsfällen, z. B. im Gesundheitswesen, ist RBAC absolut üblich und notwendig. Und es wäre schade, wenn sie REST nicht verwenden dürften, weil alle Entwickler von REST-Tools REST wie eine Religion behandeln würden.

Für mich gibt es nicht viele Möglichkeiten, eine Sitzung über HTTP aufrechtzuerhalten. Man kann Cookies mit einer sessionId oder einen Header mit einer sessionId verwenden.

Wenn jemand eine andere Idee hat, würde ich mich freuen, sie zu hören.

Answer 2

Ich denke, das Token muss alle benötigten Informationen enthalten, die in ihm verschlüsselt sind, so dass die Authentifizierung durch Validierung des Tokens und Dekodierung der Informationen erfolgt. https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

Answer 3

Nein, die Verwendung von Sitzungen verstößt nicht unbedingt gegen RESTfulness. Wenn Sie sich an die REST-Vorgaben und -Einschränkungen halten, dann ist die Verwendung von Sitzungen - zur Aufrechterhaltung des Zustands - einfach überflüssig. Schließlich erfordert RESTfulness, dass der Server keinen Zustand beibehält.

Answer 4

1. Sitzungen sind nicht RESTless
2. Meinen Sie, dass der REST-Dienst nur für die http-Nutzung geeignet ist, oder habe ich etwas falsch verstanden? Cookie-basierte Sitzungen dürfen nur für eigene(!) http-basierte Dienste verwendet werden! (Es könnte ein Problem sein, mit Cookies zu arbeiten, z.B. von Mobile/Konsole/Desktop/etc. aus)
3. Wenn Sie RESTful-Dienste für Drittentwickler anbieten, sollten Sie niemals eine Cookie-basierte Sitzung verwenden, sondern stattdessen Token, um Sicherheitsprobleme zu vermeiden.