Seite 1 von 1

Re: SQL Alchemy: Struktur für praktische Anwendung

Verfasst: Freitag 1. September 2017, 13:43
von __deets__
HTTP-Auth ist *sehr* ungewoehnlich. Das gibt es, aber das ist voellig marginal. Alleine schon weil bei HTTP (ohne S) immer die Credentials schoen lesbar fuer jeden Mann-in-der-Mitte mitlesbar sind.

Stattdessen benutzt man einfach Cookies zur Identifikation einer Session, fuer deren Erzeugung es einen expliziten login gibt.

Und Beispiele sind letztlich jede REST-API. Die Komponenten die dir ja sehr wichtig sind (und nicht zu unrecht, so soll das jetzt nicht rueberkommen), geben ja schon eine gewisse Struktur vor. Wenn du zb ein

/event/<id>/attendees

Namensraum hast, der Infos fuer ein Event vorhaelt, und die POST-Methode (oder PUT, die Unterscheidung finde ich oft artifiziell) darauf erzeugt ein neues User->Event-Mapping, dann wird das halt hinter den Kulissen mit der gerade vorgefundenen User-ID erzeugt. Der naechste Aufruf von

/event/<id>/attendees

ergibt dann halt die Liste mit dem neuen User drin.

Ob jeder x-beliebige User alle Attendees sehen darf, oder nur sich selbst (um zu checken, ob man schon drin ist), haengt jetzt wieder sehr von deiner Anwendung ab. Ein Admin zB duerfte wohl alle sehen, ein normaler User ggf. nur Leute, die als "Freunde" klassifiziert sind.

Re: SQL Alchemy: Struktur für praktische Anwendung

Verfasst: Freitag 1. September 2017, 15:36
von Sirius3
@homerunjack: die User-ID darf nie vom Client kommen und ungeprüft weiterverarbeitet werden, denn der Client könnte auch irgendeine andere ID als die eigene schicken. Wie __deets__ schon geschrieben hat, wird normalerweise ein Login über eine eigene Seite gemacht und die Daten (wie z.b. User-ID) in einer Session auf dem Server gespeichert. Die Session-ID ist so lang, dass man sie nicht erraten kann, also gefahrlos als Authentifizierungsmerkmal verwenden kann. Deine REST-API muß dann aber mit der Session-Information arbeiten, keine Ahnung, ob das dann ein fertiges Paket unterstützt.