REST, mise en cache et autorisation avec plusieurs rôles d'utilisateur

Question

Nous avons un système multi-locataires avec plusieurs niveaux d'accès différents - parfois même pour le même utilisateur car ils basculent entre plusieurs rôles. Nous commençons une discussion sur le passage à une implémentation RESTful des choses. Je commence juste à me mouiller les pieds avec tout ce truc de REST.

Alors, comment puis-je limiter l'accès aux enregistrements corrects lorsqu'ils accèdent à une ressource, en particulier lorsque la mise en cache est prise en compte? Si l'utilisateur A accède à example.com/employees, il recevra une réponse différente de celle de l'utilisateur B; l'utilisateur A peut même recevoir une réponse différente lorsqu'il passe à un rôle différent. Pour faciliter la mise en cache, l'identifiant du rôle devrait-il être incorporé d'une manière ou d'une autre dans l'uri? Peut-être quelque chose comme example.com/employees/123 (qui viole les règles de REST), ou comme une sorte de ressource subordonnée comme example.com/employees/role/123 (ce qui semble stupide, puisque role/### va être ajouté aux URI partout). Je peux aider mais je pense qu'il me manque quelque chose ici.

modifié mentionner multi-location

Answer 1

Avoir les informations d'identification utilisateur agissent comme hors d'identifiant de ressource de bande (ie. Présentant des vues différentes sur la même URL à différents rôles) se tourneront nasty sur la route. Les utilisateurs et les applications échangent des URL entre eux, les choses tournent au vinaigre lorsque cela se produit et l'URL renvoie simplement un contenu différent pour des informations d'identification différentes.

Je dirais que chaque rôle a une vision différente du monde, donc chaque rôle devrait accéder à un chemin différent au service:

• admins se connecter à example.com/admin/employees
• utilisateurs se connecter à example.com/users/employees
• rôle foo se connecte probablement example.com/foo/employees

de cette façon, vous séparer le « ce rôle voit le monde en tant que tel et tel » par t de la partie «cette vue du monde est accessible au rôle foo». Un administrateur peut se connecter à example.com/users/employees et vérifier comment un utilisateur ordinaire voit le monde, sans que l'administrateur doive d'abord emprunter l'identité d'un alias privilégié inférieur.

Vous pouvez également utiliser la partie DNS dans le même but: admin.example.com/employees vs users.example.com/employees. Ceci est particulièrement viable pour un scénario connexe, lorsque le 'rôle' n'est pas un rôle de sécurité mais un espace de noms multi-locataire (c'est-à-dire que chaque compte provisionné du service obtient sa propre 'vue' du service).