J'utilise l'authentification de base, alors Uri ressemble à http: // test: mot de passe@site.com/ .
Si je veux donner à tous les utilisateurs, je crée une uri comme http: // test: mot de passe@site.com/users/ < / a> Mais quelle adresse dois-je utiliser si je veux donner un utilisateur spécifique? Cela devrait être ou juste ou je ne sais pas. Le Raison que je pose cette question est que ce type d'autorisation signifie que URI contient déjà nom d'utilisateur. Merci d'avance.
3 Réponses :
Création d'une ressource URI de manière hiérarchique a le bénéfice que vous n'aurez aucune collision d'identité. Votre version alternative Et bien que cela ne soit pas vraiment nécessaire pour le repos, c'est l'une des choses de nommage qui facilite la tâche des humains de penser à une API de repos: "Les ressources utilisateur peuvent être trouvées dans URIS contenant l'étiquette" Utilisateurs "semble tellement normale . Se reposer elle-même est en fait Uri agnostique, donc cela ne devrait vraiment pas avoir d'importance. Mais si vous voulez utiliser des uRis significatives (lisibles humaines), je dirais retournera tous les utilisateurs . créera un nouvel utilisateur et une nouvelle ressource avec une URI. modifiera la ressource utilisateur identifiée Avec cette URI et pour accomplir des attentes raisonnables, vous devriez pouvoir obtenir cette ressource utilisateur comme dernière chose à prendre en compte: l'utilisateur autorisé peut souhaiter accéder à la ressource utilisateur pour un Différent utilisateur (aussi improbable que ce scénario pourra actuellement paraître): http: // test: mot de passe@site.com/test/ pourrait devenir problématique si vous ajoutez un autre type de ressource (E.G. Rôle) avec ID Test . Vous devrez vous assurer que vos identifiants sont uniques sur tous les types de ressources et non seulement pour un type spécifique. En outre: il n'est plus clair, que votre uri de ressources indique à un utilisateur ou à un rôle.
Le problème de base que vous avez avec cette approche est qu'une URL
// utilisateur: mot de passe@site.com/test
équivalent à
// site.com/test
Lorsque vous passez à l'aide de l'utilisation et du mot de passe comme des en-têtes d'authentification HTTP
La plupart des développeurs que je sais ne voudraient pas réussir l'utilisateur / mot de passe de l'URL, afin de choisir la deuxième option. Maintenant, vous avez un problème intéressant, car vous avez deux URL identiques indiquant exactement la même ressource, qui est contraire au repos, mais plus important encore, il est contraire à la mise en cache HTTP.
L'instant que vos utilisateurs vont à travers un proxy (et ils ne peuvent pas contrôler cela, car beaucoup de mandataires peuvent et seront utilisés par des organisations et des fournisseurs de services Internet), vous pouvez servir une version mise en cache d'un utilisateur à un utilisateur différent. Pas bien.
L'utilisateur et le mot de passe ne font pas vraiment partie de l'URL. Ils sont un mécanisme que la plupart des navigateurs acceptent de passer des en-têtes HTTP Basic Authers, mais ce n'est pas l'URL, vous devez donc fournir des URI uniques pour des ressources uniques. C'est la voie du repos et dans le cas de la demande d'accès, vous devriez être inquiet si vous ne le faites pas.
En tant que mis à part, s'il vous plaît s'il vous plaît dites-moi que vous allez mettre en œuvre https pour cela. Passer l'utilisateur et le mot de passe sur http est une très mauvaise idée. Et même si vous utilisez HTTPS, encouragez vos utilisateurs à transmettre l'utilisateur / passer incorporé dans l'URI signifie que l'utilisateur et le mot de passe vont être clairement visibles sur chaque journal du système (Apache / NGinx, App ...). C'est assez moche. Je vous recommanderais donc d'utiliser HTTPS et de décourager vos utilisateurs de transmettre des données d'authentification sur l'URL. Les données d'authentification doivent être transmises comme une partie d'un corps sur une requête postale ou comme en-tête.
C'est une excellente question. J'ai vérifié Chapitre du fitning sur le repos , le Spec HTTP et le Basic Auth RFC et ne peut pas sembler trouver une réponse définitive, mais ma meilleure estime que la partie d'authentification de l'URI n'est pas considérée comme une partie de l'identification des ressources. Ce qui signifie que vous devriez prétendre que ce n'est pas là et n'utilisez pas: comme URI pour un seul utilisateur. Voici mon raisonnement. Mise en œuvre du navigateur - La partie Auth de l'URI (test: mot de passe @) est automatiquement masquée dans mes versions actuelles de chrome et de Firefox et Internet Explorer nie une entrée directe pivotante .
Si l'utilisateur: Password @ Portion a créé l'URI de la ressource unique, alors chaque ressource pour chaque utilisateur serait unique. Cela semble juste un peu fou à la mer.
Vous ne voudriez jamais inclure un nom d'utilisateur et un mot de passe dans une référence externe comme celle-ci:
connectez-vous comme admin! Il me semble que, y compris les informations d'authentification dans l'URL, c'est un piratage qui enfreint l'apatridie et viole la première contrainte d'interface de repos ( Identification des ressources ) Mais il remplit et nécessite donc nous le balayons sous le tapis et prétendons que ce ne soit pas vraiment faisant partie de l'URL.
Ce que vous décrivez n'est pas une authentification de base. Authentification de base (et que je veux dire l'authentification de base HTTP) utilise un en-tête d'autorisation pour communiquer un nom d'utilisateur / mot de passe codé et le maintient complètement hors de l'URL. Pourquoi inventez-vous ce système?