Wir haben ein Multi-Tenant-System mit mehreren verschiedenen Zugriffsebenen - manchmal sogar für denselben Benutzer, wenn sie zwischen mehreren Rollen wechseln. Wir beginnen eine Diskussion über den Übergang zu einer REST-konformen Implementierung von Dingen. Ich fange gerade an, meine Füße nass zu machen mit der ganzen REST-Sache.
Wie gehe ich also vor, den Zugriff auf die richtigen Datensätze zu beschränken, wenn sie auf eine Ressource zugreifen, insbesondere wenn man das Caching berücksichtigt? Wenn Benutzer A Zugriff example.com/employees erhält, erhalten sie eine andere Antwort als Benutzer B; Benutzer A kann sogar eine andere Antwort erhalten, wenn er zu einer anderen Rolle wechselt. Um die Zwischenspeicherung zu erleichtern, sollte die ID der Rolle irgendwie in die URL integriert werden? Vielleicht etwas wie example.com/employees/123 (was gegen die Regeln von REST verstößt) oder als eine Art untergeordnete Ressource wie example.com/employees/role/123 (was albern erscheint, da role/### überall an URIs angehängt wird). Ich kann helfen, denke aber, dass ich hier etwas verpasse.
wurde bearbeitet, um die Mandantenfähigkeit zu erwähnen
Wenn die Benutzeranmeldeinformationen als Out-of-Band-Ressourcenbezeichner fungieren (dh unterschiedliche Ansichten derselben URL für verschiedene Rollen darstellen), wird das ganze nicht so einfach. Benutzer und Anwendungen tauschen URLs zwischen ihnen aus. Wenn dies geschieht, werden die Dinge sauer und die URL gibt einfach einen anderen Inhalt für die verschiedenen Anmeldeinformationen zurück.
Ich würde sagen, dass jede Rolle eine andere Sicht auf die Welt hat, daher sollte jede Rolle auf einen anderen Pfad zum Dienst zugreifen:
Auf diese Weise trennst du die "diese Rolle sieht die Welt als solche und solche" Teil von der "diese Sicht der Welt ist zugänglich für Rolle foo" Teil. Ein Administrator kann sich mit example.com/users/employees verbinden und überprüfen, wie ein normaler Benutzer die Welt sieht, ohne dass der Administrator zuerst einen niedrigeren privilegierten Alias annehmen muss.
Sie können den DNS-Teil auch für denselben Zweck verwenden: admin.example.com/employees vs. users.example.com/employees. Dies ist besonders dann sinnvoll, wenn die "Rolle" keine Sicherheitsrolle ist, sondern ein Multi-Tenant-Namespace (dh jedes Service-Provisioning-Konto erhält seine eigene "Ansicht" des Service).
Tags und Links rest caching authorization roles