Faire des séances de vraiment violent de la Détente?

Est à l'aide de sessions dans une API RESTful vraiment violation de la Détente? J'ai vu beaucoup d'avis allant à l'une ou l'autre direction, mais je ne suis pas convaincu que les sessions sont Agité. De mon point de vue:

l'authentification n'est pas interdite pour la Détente (sinon il y aurait peu d'utilité dans les services RESTful)
l'authentification se fait par l'envoi d'un jeton d'authentification dans la demande, généralement de l'en-tête
ce jeton d'authentification doit être obtenue en quelque sorte et peut être révoquée, auquel cas il doit être renouvelé
le jeton d'authentification doit être validé par le serveur (sinon il ne serait pas d'authentification)

Alors, comment faire des sessions de violer cette?

côté client, les sessions sont réalisées à l'aide des cookies
les cookies sont tout simplement un extra-tête HTTP
un cookie de session peut être obtenu et révoquée à tout moment
les cookies de session peut avoir une durée de vie infinie temps en cas de besoin
l'id de session (jeton d'authentification) est validé côté serveur

En tant que tel, pour le client, un cookie de session est exactement le même que tout autre en-tête HTTP de base du mécanisme d'authentification, sauf qu'il utilise la Cookie en-tête de la place de la Authorization ou certains autres propriétaires d'en-tête. Si il n'y a pas de session attachés à la valeur du cookie côté serveur, pourquoi cela ferait-il une différence? Du côté serveur, la mise en œuvre n'a pas besoin de préoccupation au client tant que le serveur se comporte Reposant. En tant que tel, les cookies en eux-mêmes ne doivent pas faire une API Agité, et les séances sont simplement des cookies pour le client.

Sont mes hypothèses de mal? Ce qui rend les cookies de session Agité?

J'ai couvert qui est exactement la question ici: stackoverflow.com/questions/1296421/rest-complex-applications/...
Ajouter à cela, si vous êtes seulement en utilisant la session d'authentification, alors pourquoi ne pas utiliser les en-têtes? Si non, et que vous utilisez la session pour les autres de l'état de la conversation, alors que c'est violer les Apatrides contrainte de REPOS.
Merci. Il semble que vous parlez de la sessions pour stocker temporairement les données transmises par les internautes, alors que dans mon cas, je suis juste en train de parler d'eux comme un détail de l'implémentation de l'authentification. Cela peut-il être où le désaccord vient d'où?
Hartung: pas de différence significative du protocole de point de vue. Filtre doit également être conservé sur le côté serveur et le filtre code doit être toujours transmis. 100% le même que pour les séances.
Mon seul point est que si vous allez utiliser un en-tête pour représenter un jeton d'authentification, HTTP fournit un au-delà d'un générique de cookie. Alors, pourquoi ne pas l'utiliser et de conserver la gratuit de la sémantique que vous obtenez avec elle (quelqu'un de voir la charge utile peut voir qu'il y a un jeton d'authentification, est attribué à).
Il ne suffit pas de protocole, c'est à propos de la sémantique aussi.
Donc, tout le débat est simplement un problème de syntaxe? 🙂 Si le Authorization en-tête se sont comportés exactement le même comme un cookie de session, il serait parfaitement Paisibles? Je suis d'accord que les témoins se sentent un peu "sale", mais il n'y a pas de différence technique.
Hartung: toujours pas de voir la différence. Vous avez donné le nom différent à la même technique. Nous pouvons le nom de ce filtre, mais c'est encore une session.
Certes, mais alors pourquoi ne pas faire vos propres en-têtes, ou de détourner certains autres d'en-tête pour le jeton d'authentification. Utiliser le X-XYZZY en-tête. C'est juste la syntaxe de droit? Les en-têtes de transmettre de l'information. L'en-tête d'Autorisation est plus de "l'auto-documentation" que votre cookie est, parce que "tout le monde" savoir ce que l'en-tête d'Authentification est pour. Si ils voient juste JSESSIONID (ou autre), ils ne peuvent pas faire toutes les hypothèses, ou pire, de faire le mauvais hypothèses (quoi d'autre est-il stocker dans la session, quoi d'autre est-ce utilisé pour, etc.). Avez-vous le nom de vos variables dans votre code Aq12hsg? Non, bien sûr que non. La même chose s'applique ici.
Non, c'est un Filtre. Un Filtre a différentes sémantiques qu'une Session. Cycle de vie différent, les différents flux de travail, des objectifs différents.
Hartung: ne Peut pas avoir l'idée alors :-S à Partir de votre post, je l'ai trouvé tout à fait similaire.
Cette opinion basée question est une violation des règles. Beaucoup de bonnes questions générer un certain degré d'opinion basée sur les experts de l'expérience, mais les réponses à cette question ont tendance à être presque entièrement basé sur des opinions, plutôt que des faits, des références, ou des compétences spécifiques. Si cette question peut être reformulé de manière à adapter les règles dans le centre d'aide, veuillez modifier la question.

InformationsquelleAutor deceze | 2011-05-20

290

Tout d'abord, définissons quelques termes:
- Reposante:
  
  On peut caractériser les applications conformes pour le RESTE les contraintes
  décrit dans cette section comme "RESTful".[15] Si un service de viole
  de la nécessaire les contraintes, il ne peut pas être considéré comme Reposant.
  
  selon wikipédia.
- apatrides contrainte:
  
  Nous avons ensuite ajouter une contrainte à l'interaction client-serveur:
  la communication doit être apatrides dans la nature, comme dans le
  client-apatride-serveur (CSS) le style de la Section 3.4.3 (Figure 5-3),
  de telle sorte que chaque demande du client vers le serveur doit contenir tous les
  informations nécessaires à la compréhension de la demande, et ne peut pas prendre
  avantage de toute stockées contexte sur le serveur. L'état de Session est
  donc gardé entièrement sur le client.
  
  selon la Fielding thèse.
Donc côté serveur séances de violer les apatrides contrainte de REPOS, et ainsi de Repos soit.

En tant que tel, pour le client, un cookie de session est exactement le même que n'importe quel
d'autres en-tête HTTP de base du mécanisme d'authentification, sauf qu'il utilise
l'en-tête de Cookie au lieu de l'Autorisation ou de certains autres
propriétaire d'en-tête.

Par les cookies de session vous stocker l'état du client sur le serveur et si votre demande a un contexte. Nous allons essayer d'ajouter un équilibreur de charge et une autre instance de service de votre système. Dans ce cas, vous devez partager les sessions entre les instances du service. Il est difficile de maintenir et d'étendre un tel système, alors qu'il évolue mal...

À mon avis il n'y a rien de mal avec les cookies. La technologie des cookies est un mécanisme de stockage dans lequel les données enregistrées est automatiquement associé à cookie en-têtes de chaque demande. Je ne sais pas du RESTE de la contrainte qui a un problème avec ce type de technologie. Donc, il n'y a pas de problème avec la technologie elle-même, le problème est avec son utilisation. Fielding a écrit une sous-section au sujet de pourquoi il pense que les cookies HTTP sont mauvais.
De mon point de vue:
- l'authentification n'est pas interdite pour la Détente (sinon il y aurait peu d'utilité dans les services RESTful)
- l'authentification se fait par l'envoi d'un jeton d'authentification dans la demande, généralement de l'en-tête
- ce jeton d'authentification doit être obtenue en quelque sorte et peut être révoquée, auquel cas il doit être renouvelé
- le jeton d'authentification doit être validé par le serveur (sinon il ne serait pas d'authentification)
Votre point de vue était assez solide. Le seul problème était avec le concept de la création de jeton d'authentification sur le serveur. Vous n'avez pas besoin de cette partie. Ce que vous avez besoin est de stocker le nom d'utilisateur et mot de passe sur le client et l'envoyer avec chaque demande. Vous n'avez pas besoin de plus pour faire ce que HTTP basic auth et d'une connexion chiffrée:
- La Figure 1. - D'apatride, de l'authentification par la confiance des clients
Vous avez probablement besoin d'une mémoire auth cache côté serveur pour rendre les choses plus vite, car vous devez vous authentifier à chaque demande.

Maintenant, cela fonctionne assez bien par la confiance des clients écrit par vous, mais qu'en 3ème partie de la clientèle? Ils ne peuvent pas avoir le nom d'utilisateur et le mot de passe et de toutes les autorisations des utilisateurs. Donc, vous avez à stocker séparément les autorisations que d'un 3ème partie client peut disposer d'un utilisateur spécifique. Si le client les développeurs peuvent s'inscrire ils 3ème partie clients, et obtenir une clé API unique et les utilisateurs peuvent autoriser la 3e partie des clients d'accéder à une partie de leurs autorisations. Comme la lecture, le nom et l'adresse e-mail, ou la liste de leurs amis, etc... Après une 3ème partie client, le serveur va générer un jeton d'accès. Ces jeton d'accès peut être utilisé par la 3ème partie client d'accéder aux autorisations octroyées par l'utilisateur, comme suit:
- La Figure 2. - D'apatride, de l'authentification par le 3e partie des clients
Donc la 3ème partie, le client peut obtenir le jeton d'accès à partir d'un client de confiance (ou directement auprès de l'utilisateur). Après cela, il peut envoyer une requête valide de la avec la clé API et le jeton d'accès. C'est le plus basique de la 3e partie auth mécanisme. Vous pouvez lire plus sur les détails de mise en œuvre dans la documentation de chaque 3ème partie auth système, par exemple le protocole OAuth. Bien sûr, cela peut être plus complexe et plus sécurisé, par exemple, vous pouvez vous inscrire les détails de chaque demande unique sur le côté serveur et envoyer la signature avec la demande, et ainsi de suite... La solution réelle dépend de votre application a besoin.
- Oui, vous êtes complètement à droite. Depuis que j'ai posté cette question que j'ai totalement venir autour pour voir que. Les cookies de Session ne sont pas quelque chose de spécial quand on le regarde dans les détails techniques, mais qui manque de la forêt pour les arbres. Accepté votre réponse en raison des beaux diagrammes. 😉
- Je ne suis pas sûr de savoir si tous sont d'accord ou pas. J'ai trouvé un meilleur tableau de ici: i.stack.imgur.com/snQSG.png sur oauth. Donc je pense que maintenant que l'autorisation doit être une couche entre le client REST et le RESTE, et le RESTE ne devrait pas connaître les autorisations ou quoi que ce soit d'autre. Seulement de cette façon, est-il correct je pense. Cette approche réduit les options de développement d'API REST-s, mais je pense qu'il est encore utilisable. J'essaie de donner un exemple d'application à la preuve que l'ASAP.
- Ok, j'ai repensé, la réponse du service de REPOS ne doit pas dépendre de l'autorisation, donc je pense que les 2 premières solutions sont 100% d'accord, et les autres sont d'accord si le service utilise ces informations uniquement pour décider s'il autorise ou non à la demande. Donc, je pense que les autorisations utilisateur doit d'effet sur la représentation des ressources actuelles.
- Je vais créer une question sur les autorisations de dépendance de représentations. Je vais étendre cette réponse dès que j'ai eu la bonne solution.
- il est vrai qu'un service RESTful ne peut pas compter sur les cookies de session pour l'authentification dans la façon dont il est traditionnellement mis en œuvre. Toutefois, vous pouvez utiliser des cookies afin d'effectuer l'authentification si le cookie contient toutes les informations d'état du serveur aura besoin plus tard. Vous pouvez également rendre le cookie l'abri de toute altération par la signature avec une paire clé publique/privée. Voir mes commentaires ci-dessous.
- Oui, je suis d'accord. Traditionnelles séances de stocker l'état de l'application et des ressources de l'état à la même place sur le serveur, de sorte que leur utilisation n'est pas reposant... l'Utilisation de cookies est une chose différente. Vous stocker des cookies sur le côté client, donc il peut contenir l'état de l'application.
- Je suis en cours d'exécution d'un SPA et il me semble qu'il n'y a pas moyen pour moi d'avoir une clé publique / privée d'installation qui n'est pas en clair quelque part. J'ai aussi entendu parler de certains régimes où le cookie stocke des données de toutes les autorisations, et par chiffrement / hachage du cookie (ils référencé AWS et HMAC), vous pouvez vous épargner beaucoup de db appels pour vérifier les autorisations. Ne soit de ces sons est-elle réalisable?
- Je suis par avec inviolable cookies conformément à cet article: hacks.mozilla.org/2012/12/... des choses Très intéressantes. Un peu précis quand même. YMMV.
- Supprimé les anciennes figures, simplifié l'explication.
- Cette question est difficile à résoudre, je pense que, dans la pratique, les outils doivent être au développeur du service et non l'inverse, pour moi Restful (comme tout autre "outil" ou de la méthode de travail) n'est pas une définition de wikipedia. Si vous avez à faire des choses simples pour résoudre vos besoins, alors Il n'a pas d'importance si vous violez ou pas Reposante, Si que de soucis pour vous, alors inventer un nouveau terme et de l'appeler: Stateful, je me souviens que dans les années quatre-vingt dix, quand peut les puristes l'habitude de dire: Absolument PAS! de HTML Dynamique, et maintenant, à vous de voir...
- Il y a une très bonne définition de ce qui RESTE et de ce pas. Le seul problème ici (je pense) que les gens sont paresseux pour lire l'introduction de la dissertation et ils appellent tout de REPOS, de détente, etc..., qui utilise les ressources et les méthodes du protocole HTTP pour CRUD. Le REPOS est plus que cela. Vous exemple de HTML dynamique a été un tout autre problème, étant donné que c'était une innovation et non pas de l'incompréhension d'un bien décrit à la technologie.
- Je comprends votre point de vue, les êtres humains ont besoin de définitions, qui les font se sentir plus à l'aise, c'est dans notre nature (le problème avec le fait d'essayer de définir chaque chose et être très stricte de ses le contraire de la créativité). Mon point était que. Désolé si j'ai été hors de l'objet de l'ouverture de la discussion à cet égard. Nous ne sommes pas des ordinateurs, après tout 😉 ... il y a trois phrases qui guide ma pensée, peu importe ce que les autres avaient à dire : "La fin justifie les moyens","tout est relatif" et "je ne suis pas d'accord avec ce que vous avez à dire, mais je vais défendre jusqu'à la mort votre droit de le dire". Ce qui concerne
- Complètement hors-sujet sous-question. Ces diagrammes, vous avez utilisé pour fournir des images pour votre réponse sont belles. À tout hasard, vous pouvez dire le secret, le logiciel qui permet de dessiner un si fabuleux schémas?
- Cette question semble faire l'hypothèse que les sessions sont stockées sur le serveur, lorsque de nombreux cadres de permettre aux utilisateurs de stocker les sessions dans la base de données, l'équilibrage de la charge de travail de l'amende juste. Si ce est utilisé, ne serait-ce pas admissible?
- Par le REPOS la plupart de nos clients sont sur le côté serveur, donc la réponse dépend de ce que les sessions sur ce serveur... Par l'énorme charge, vous aurez besoin de mise à l'échelle horizontale, parfois sur plusieurs endroits différents à travers le monde. Cela signifie que plusieurs session de stockages dont vous avez besoin pour synchroniser en quelque sorte. Par les charges plus petites, vous pouvez gérer avec un seul serveur, le stockage des sessions, ainsi qu'avec les ressources de l'état ne fait pas de mal que bien. L'Ofc. c'est juste un argument contre le "côté serveur sessions", il y a beaucoup plus de...
- Vous avez dit: "Par les cookies de session vous stocker l'état du client sur le serveur et si votre demande a un contexte. Nous allons essayer d'ajouter un équilibreur de charge et une autre instance de service de votre système. Dans ce cas, vous devez partager les sessions entre les instances du service. Il est difficile de maintenir et d'étendre un tel système". Mais n'est-il pas de même pour le serveur pour vérifier le nom d'utilisateur et le mot de passe?
- Si vous maintenez la session sur le côté serveur et vous disposez de plusieurs serveurs, alors vous avez à synchroniser entre ces serveurs, ainsi par exemple, lorsque l'un d'eux descend, puis un autre peut prendre sa place sans perdre les données de la session. Cette session de synchronisation est la cause de la mauvaise évolutivité horizontale. Le maintien de la session sur le client élimine ce problème. Faire le nom d'utilisateur et le mot de passe de vérification plus rapide n'est pas un problème difficile; par exemple, vous pouvez utiliser un cache en mémoire sur le serveur réel.
- Je pense que vous devez vous demander si vous avez vraiment besoin d'une API REST. Il n'est généralement pas la solution raisonnable. Je veux dire, il y a de nombreuses contraintes, la plupart des devs de ne pas comprendre ou de se soucier. Il faut beaucoup apprendre à le faire correctement et les avantages qui en vaut la peine seulement par vraiment de grands services. Il est beaucoup plus facile de faire ce que vous comprenez déjà essayer avec un projet de loisirs.
- "Cette session de synchronisation est la cause de la mauvaise évolutivité horizontale.". N'est-ce pas le nom d'utilisateur et le mot de passe de synchronisation d'une cause de mauvaise évolutivité horizontale? Une fois que vous mettez à jour le mot de passe, tous les serveurs doivent le savoir.
- Mise à jour le mot de passe est un événement rare. Mise à jour d'une variable de session est un événement fréquent...
- Que pensez-vous d'une clé API pour le contrôle de la fréquence? Est-ce une session ou un jeton?
- Je ne comprends pas pourquoi tout le monde semble accepter le commentaire, vous devez stocker les mots de passe sur le côté client et de les envoyer avec chaque demande. C'est une très mauvaise pratique qui met en danger vos clients des données sensibles. Un unhashed mot de passe (qu'il faudrait l'envoyer sur et plus) ne doivent jamais être stockées n'importe où. Si nous acceptons cela, alors vous utilisez des jetons, comme la plupart des systèmes d'authentification faire, auquel cas, quel que soit le mécanisme que nous utilisons à l'échelle de l'jetons de dépôt aura surtout l'égalité de l'évolutivité des problèmes que n'importe quelle session d'évolutivité.
InformationsquelleAutor inf3rno
329

Tout d'abord, le REPOS n'est pas une religion et ne doit pas être abordé comme tel. Bien qu'il existe des avantages pour les services RESTful, vous devez suivre les principes de REPOS aussi loin qu'ils le font sens pour votre application.

Cela dit, l'authentification et le côté client de l'état de ne pas violer le RESTE principes. Tandis que le RESTE exige que les transitions de l'état d'apatride, c'est en se référant au serveur lui-même. Au cœur, de tout de REPOS est sur les documents. L'idée derrière l'apatridie est que le SERVEUR est apatride, pas les clients. Tout client de la délivrance d'une demande identique (même les en-têtes, les cookies, les adresses URI, etc) doivent être prises à la même place dans l'application. Si le site web stocké à l'emplacement actuel de l'utilisateur et la navigation gérée par une mise à jour côté serveur de navigation variable, puis le RESTE serait violé. Un autre client à l'identique les informations de la demande serait pris à un emplacement différent en fonction du côté serveur de l'état.

Google services web sont un exemple fantastique d'un système Reposant. Ils ont besoin d'un en-tête d'authentification avec l'authentification de l'utilisateur de la clé pour être passé sur chaque demande. Cela ne violent RESTE principes légèrement, parce que le serveur est suivi de l'état de la clé d'authentification. L'état de cette clé doit être maintenu et il a une sorte de date d'échéance/durée au bout de laquelle il n'accorde plus d'accès. Cependant, comme je l'ai déjà mentionné au début de mon post, des sacrifices doivent être faits pour permettre à une application de réalité de travail. Cela dit, les jetons d'authentification doit être stocké dans une manière qui permet à tous les clients possibles à continuer d'accorder l'accès au cours de leur temps. Si un serveur est la gestion de l'état de la clé d'authentification au point qu'un autre serveur d'équilibrage de charge ne peut pas prendre plus de répondre aux demandes fondées sur cette touche, vous avez commencé à vraiment de violer les principes de REPOS. Les services de Google en sorte que, à tout moment, vous pouvez prendre un jeton d'authentification que vous utilisez sur votre téléphone contre équilibrer la charge du serveur et de frapper l'équilibre de la charge du serveur B à partir de votre bureau tout en ayant accès au système et être dirigé vers les mêmes ressources si les demandes étaient identiques.

Ce que tout se résume à ce que vous avez besoin pour vous assurer que vos jetons d'authentification sont validées par rapport à un magasin de sauvegarde d'une certaine sorte (base de données, le cache, peu importe) pour vous assurer que vous préserver comme bien d'autres propriétés que possible.

J'espère que tout cela fait sens. Vous devriez également vérifier la Les contraintes section de la article de wikipédia sur Representational State Transfer si vous ne l'avez pas déjà. Il est particulièrement éclairante quant à ce que les principes de REPOS sont en fait discuter le pour et pourquoi.
- C'est exactement comment je vois le REPOS ainsi. Pour autant que je suis conscient qu'il est pratiquement impossible de créer un mécanisme d'authentification qui n'est pas dynamique, à un certain degré, de sorte que si l'authentification, en général, est Inquiet.
- Je voudrais reformuler votre déclaration initiale. Seulement le REPOS si les contraintes de REPOS donner un sens à votre demande. Vous êtes libre d'appliquer un sous-ensemble de ces contraintes et vous obtiendrez un sous-ensemble des prestations. Toutefois, à ce stade, vous avez créé votre propre style architectural. Ce n'est pas une mauvaise chose si, en fait, c'est ce que les quatre premiers chapitres de Roy thèse sont sur le, fondée sur des principes de conception. RESTE était juste un exemple.
- Êtes-vous sûr que le Google auth jeton qui n'ont pas de date d'expiration codé en elle? Ne semble pas comme il devrait être de deux dur à faire.
- Juste assez de point. Je suis honnêtement pas sûr de savoir comment Google fait-il, mais le délai d'expiration peut être codé dans le jeton d'authentification. Je crois que mon plus gros point tient toujours bien. Il y a certains types de l'etat qui doit tout simplement être maintenu et aussi longtemps que vous comprenez pourquoi appels de REPOS pour les cas d'apatridie, vous pouvez violer dans une manière qui fait sens avec beaucoup de répercussions sur le reste du système et les avantages d'une bonne architecture.
- Depuis pas d'autres arguments ont été réalisés jusqu'à présent, je suis en acceptant ce bien d'une réponse écrite. Je pense que l'important, c'est que serveur sans état (stateless ne veut pas dire serveur sans état (stateless, quelque chose qui, je pense, est souvent mal comprise ou mal appliqué. Le serveur peut (et généralement de doit) ont tout de l'état qu'il veut, tant qu'il se comporte de la quantité.
- J'en ai entendu beaucoup de prédication que les sessions ne sont pas de tout repos. L'authentification HTTP de base est un véritable pas en arrière si vous essayez de construire une application web bien.
- Il est possible de créer un parfaitement Reposant système d'authentification. Si Google encode les informations d'authentification, c'est à dire la date d'expiration plus un jeton codée par une clé privée connue de tous les serveurs de Google, alors il pourrait être tout à fait Reposant. Je ne suis pas pour les guerres de religion, mais si les gens vont appeler leurs Api RESTful alors ils doivent savoir ce que cela signifie. Il y a trop d'knuckleheads les jeter dans les derniers mots à la mode avec aucune idée de ce qu'ils signifient.
- si l'état de l'authentification ne peut pas être validé par un serveur, il peut être forgé. Je pourrais désosser mon jeton de modifier ma date d'expiration, par exemple. Ou je pourrais faire semblant d'être quelqu'un d'autre en prenant leur jeton d'authentification. Il s'agit de ce qui est plus important pour le développeur ou de l'organisation: l'Adhésion à une application style architectural ou de la protection de l'identité.
- Henning, vous faire l'hypothèse erronée que le serveur requiert des informations d'état pour valider le jeton d'authentification. Nous pouvons raisonnablement supposer que vous ne pouvez pas vous forge un jeton qui a été signé par une paire clé publique/privée si vous ne connaissez pas la clé privée. Pour vérifier le jeton est valable tous vous avez besoin est la clé publique. Je maintiens que complètement Reposant authentification est possible.
- Oui, je suis complètement d'accord. Votre commentaire m'a fait penser... j'ai Donc créé un apatride et sessionless l'authentification et l'autorisation de la bibliothèque basé lâchement sur la conception de Kerberos. Il fonctionne à merveille, et semble être très sécurisé. Toutefois, en raison des demandes ne peut pas réaliser de manière fiable les données du corps, chaque ressource protégée qui devrait être accessible via GET doit plutôt être accessibles via des POST ou PUT. Je n'ai pas trouvé un moyen de s'attaquer encore.
- si vous n'avez pas la possibilité d'envoyer un corps de données, pourquoi ne pas utiliser l'en-tête HTTP WWW-Authenticate pour qui? Prendre Amazonie comme une source d'inspiration de la ressource: docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html, ils ont défini AWS côté de Digest et Basic. Le navigateur ne sait probablement pas comment gérer AWS authentifications, de sorte qu'il ne sera pas afficher la fenêtre de connexion, si vous ne voulez pas le navigateur pour l'afficher et, par conséquent, décidé de ne pas utiliser cet en-tête.
- Merci pour cette! Je vais regarder plus en détail bientôt.
- Je pense que vous venez de dire que l'utilisation d'un jeton qui inclut une date d'expiration et la signature, vous pouvez avoir un véritable apatrides Reposant solution d'authentification. Mais pratiquement, il n'existe aucun moyen d'invalider ce jeton. Si le jeton est de longue durée, alors vous avez un problème de sécurité si le jeton est volé. Si le jeton est de courte durée, vous devez tenir régulièrement de générer de nouveaux jetons (ce qui implique de disposer de l'utilisateur à entrer son nom d'utilisateur & mot de passe et à la fin, n'est-ce pas le mot de passe utilisateur de l'état de toute façon??) (Ne cherche pas à être argumentatif, juste essayer d'obtenir ma tête autour de cela)
- Si une longue durée de vie du jeton est volé, cela signifie que l'utilisateur de la machine a été compromise, dans ce cas, tous les paris sont éteints. Cependant, de courte durée, les jetons sont une option.Vous pouvez permettre à l'utilisateur de renouveler le jeton à l'ancienne alors qu'elle est encore vivante. Cela évite le problème d'avoir à se réauthentifier mais est délicate et un adversaire pourrait faire de même. L'utilisateur passe à l'état. Remarque, que l'utilisateur pourrait présenter un vieux jeton et le mot de passe, crypté. Seul le serveur peut déchiffrer l'ancien jeton et vérifier le mot de passe.
- Si une longue durée de vie du jeton est volé, cela signifie que l'utilisateur de la machine a été compromise, dans ce cas, tous les paris sont éteints. Cependant, de courte durée, les jetons sont une option. L'utilisateur pourrait présenter un vieux jeton et le mot de passe, crypté. Seul le serveur peut déchiffrer l'ancien jeton et vérifier le mot de passe. Ensuite, il serait question d'un nouveau jeton. Alternativement, l'utilisateur peut présenter une durée non écoulée du jeton et demandent à être actualisées. Bien sûr, un adversaire pourrait en faire de même. Je suis d'accord les mots de passe sont l'état, mais l'état peut être maintenu à côté client.
- tout d'Abord, le REPOS n'est pas une religion et ne doit pas être abordé comme tel. Bien qu'il existe des avantages pour les services RESTful, vous devez suivre les principes de REPOS aussi loin qu'ils le font sens pour votre application. - cependant, je pourrais VOUS faire une religion, pour le dire. Je vous remercie. Utilisez ce qui fonctionne pour vos besoins...ce qui un concept.
InformationsquelleAutor Jared Harding
12

Les Cookies ne sont pas pour l'authentification. Pourquoi réinventer la roue? HTTP est bien conçu, les mécanismes d'authentification. Si nous utilisons des cookies, nous tombons dans l'aide de HTTP comme protocole de transport seulement, donc nous avons besoin de créer notre propre système de signalisation, par exemple, pour indiquer aux utilisateurs qu'ils ont fournis mal d'authentification (à l'aide de HTTP 401 serait incorrect que nous n'aurions probablement pas d'alimentation Www-Authenticate à un client, que HTTP spécifications de besoin 🙂 ). Il convient également de noter que Set-Cookie n'est qu'une recommandation pour le client. Son contenu peut être ou peut ne pas être enregistré (par exemple, si les cookies sont désactivés), tandis que Authorization en-tête est automatiquement envoyé à chaque requête.

Un autre point est que, pour obtenir une autorisation de cookie, vous aurez probablement besoin de fournir vos informations d'identification, quelque part en premier? Si oui, alors ne serait-il pas Inquiet? Exemple Simple:
- Vous essayez GET /a sans cookie
- Vous obtenez une demande d'autorisation de quelque sorte
- Vous aller et autorise en quelque sorte comme POST /auth
- Vous obtenez Set-Cookie
- Vous essayez GET /a avec cookie. Mais ne GET /a se comporter idempotently dans ce cas?
Pour résumer cela, je crois que si nous avons accès à certaines ressources et nous avons besoin de s'authentifier, puis nous doit s'authentifier sur la même ressource, pas n'importe où ailleurs.
- En attendant je suis venu autour de plus de ce point de vue-là. Je pense que, techniquement, il ne fait guère de différence, c'est juste toutes les en-têtes HTTP. Il est vrai cependant que le comportement d'authentification lui-même n'est pas Reposant, si la connexion par adresse. Si les cookies ne sont qu'un symptôme d'un problème plus important avec le système d'authentification.
- Ce n'est pas vraiment en compte le fait que les navigateurs ne supportent qu' Authorization: Basic ou Digest. Si vous voulez faire quelque chose de plus avancé que sur la base de la digérer auth (et vous devriez), dans un contexte du navigateur, puis vous allez avoir besoin d'autre chose que de la Authorization en-tête.
- Je ne pense pas que c'est un problème pour transporter, disons, Porteur du jeton dans Authorization en-tête, même dans un contexte du navigateur.
- Car il n'y a aucun moyen d'obtenir le navigateur à utiliser un porteur de jeton pour, par exemple, une demande de page.
- Je suppose que c'est l'un des rares cas lors de la demande de page HTML directement à partir de l'API REST. Dans le cas vous avez une sorte de JS client basé sur ce qui pourrait composer tout en-tête d'Autorisation que vous aimez.
- Absolument - si tu fais de la pure JS, alors les choses sont fondamentalement OK (sauf, par exemple, les Websockets). Mais mon point est que l'API de base de auth n'est pas nécessairement la seule considération dans un navigateur scénario.
- GET /a sans un cookie, un cookie sont clairement deux différentes demandes, et il est acceptable pour eux de se comporter différemment.
InformationsquelleAutor starteleport
7

En fait, la Détente ne s'applique qu'aux RESSOURCES, comme indiqué par une Universal Resource identifier. Donc à même de parler de choses comme les en-têtes, les cookies, etc. en ce qui concerne le RESTE n'est pas vraiment approprié. RESTE peut travailler sur n'importe quel protocole, même si elle arrive à être fait de façon systématique sur HTTP.

Le principal déterminant est ceci: si vous envoyez un RESTE d'appel, ce qui est une URI, puis une fois l'appel fait avec succès sur le serveur, est-ce que l'URI de retour le même contenu, dans la mesure où les transitions ont été effectuées (PUT, POST, DELETE)? Ce test permettrait d'exclure les erreurs ou les demandes d'authentification étant retourné, parce que dans ce cas, la demande n'a pas encore fait sur le serveur, ce qui signifie la servlet ou de l'application qui va renvoyer le document correspondant à l'URI.

De même, dans le cas d'un POST ou PUT, pouvez-vous envoyer un URI/charge utile, et peu importe combien de fois vous envoyer le message, il sera toujours mise à jour de la base des mêmes données, de sorte que par la suite, Obtient retournera un résultat cohérent?

RESTE est au sujet de l'application de données, pas sur le faible niveau d'information requis pour obtenir que les données transférées sur.

Dans le blog suivant, Roy Fielding a donné un bon résumé de tout REPOS idée:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"Reposant système passe d'un état stable à l'
ensuite, et ce à l'état d'équilibre est à la fois un potentiel de départ de l'état-
et un potentiel de l'état final. I. e., un Réparateur est un système inconnu
nombre de composants obéissant à un ensemble de règles simples, tels qu'ils
sont toujours soit au REPOS ou au passage d'un Réparateur
état à un autre Réparateur de l'état. Chaque état peut être complètement
compris par la représentation(s) qu'elle contient et l'ensemble de
les transitions qu'il fournit, avec les transitions limitée à un
uniforme d'actions pour être compréhensible. Le système peut être
un complexe diagramme d'état, mais chaque agent utilisateur ne peut voir que
un état à un moment (l'actuel état d'équilibre) et donc chaque
l'état est simple et peut être analysées de façon indépendante. Un utilisateur, otoh, que,
est en mesure de créer leurs propres transitions à tout moment (par exemple, entrez
une URL, sélectionnez un signet, ouvrez un éditeur, etc.)."

Aller à la question de l'authentification, si elle est accomplie par le biais de cookies ou des en-têtes, tant que l'information n'est pas une partie de l'URI et de la POST-charge utile, il n'a vraiment rien à voir avec le REPOS à tous. Donc, en ce qui concerne les apatrides, nous parlons de l'application des données uniquement.

Par exemple, que l'utilisateur entre des données dans un écran graphique, le client est de garder la trace de ce que les champs ont été inscrits, qui n'ont pas, tous les champs obligatoires sont manquants, etc C'est tout ce CONTEXTE CLIENT et ne doivent pas être envoyés ou suivis par le serveur. Ce qui est envoyée au serveur est l'ensemble des champs qui doivent être modifiées dans les ressources (par l'URI), tels qu'une transition se produit de cette ressource à partir d'un Réparateur état à l'autre.

Ainsi, le client conserve la trace de ce que l'utilisateur est en train de faire, et il n'envoie logiquement compléter les transitions de l'état du serveur.
- Je ne vois pas comment cela met la lumière sur la question posée.
InformationsquelleAutor Ken Kopelson
1

HTTP transaction, authentification d'accès de base, n'est pas adapté pour RBAC, parce que l'authentification d'accès de base utilise le cryptage nom d'utilisateur:mot de passe à chaque fois d'identifier, de tout ce qui est nécessaire dans RBAC est le Rôle de l'utilisateur veut utiliser pour un appel spécifique.
RBAC ne pas valider les autorisations sur le nom d'utilisateur, mais sur des rôles.

Vous pourriez tric autour de concaténer comme ceci: usernameRole:mot de passe, mais c'est une mauvaise pratique, et il est également inefficace parce que lorsqu'un utilisateur a plusieurs rôles, l'authentification moteur aurait besoin de tester tous les rôles dans la concaténation, et que chaque appel de nouveau. Ce serait détruire l'un des plus grands avantages techniques de RBAC, à savoir très rapidement une autorisation d'essai.

De sorte que le problème ne peut être résolu à l'aide authentification d'accès de base.

Pour résoudre ce problème, à la session de maintenance est nécessaire, et qui semble, selon certaines réponses, en contradiction avec le RESTE.

C'est ce que j'aime au sujet de la réponse que le REPOS ne doit pas être considéré comme une religion. Dans un complexe d'affaires des cas, dans les soins de santé, par exemple, RBAC est absolument commun et nécessaire. Et il serait dommage qu'ils ne seraient pas autorisés à utiliser REPOSER, parce que tout le RESTE-les outils de concepteurs auraient traiter RESTE comme une religion.

Pour moi il n'y a pas beaucoup de façons de maintenir une session HTTP. On peut utiliser des cookies, avec un id de session, ou un en-tête avec un id de session.

Si quelqu'un a une autre idée je serai heureux de l'entendre.

InformationsquelleAutor Bert Verhees
-4
1. Les séances ne sont pas Agités
2. Voulez-vous dire que le REPOS de service pour http-utiliser seul ou j'ai eu qch mal? Basé sur un Cookie de session doit être utilisé uniquement pour propre(!) les services basés sur http! (Il pourrait être un problème pour travailler avec des cookies, par exemple, à partir d'un Mobile/Console/ordinateur de Bureau/etc.)
3. si vous fournissez un service RESTful pour la 3d développeurs tiers, ne jamais utiliser des cookies de session, utiliser des jetons à la place pour éviter les problèmes avec la sécurité.
- le cookie ne doit pas être utilisé pour stocker une clé de session pour une session sur le serveur qui détient le jeton d'authentification. mais si le cookie détient le jeton d'authentification elle-même, c'est une solution possible. (bien sûr, le cookie doit être httponly et sécurisé)
InformationsquelleAutor Maxim

Vous devez vous connecter pour publier un commentaire.