Discussion :

[Rohan21]

Bonsoir à tous,

Voila j'ai mis en place un service web REST et j'ai besoin d'authentifier mes clients.
J'ai vu qu'il existait plusieurs méthode dont celle du jeton d’authentification, que je vais détailler le fonctionnement:

L'idée consiste à envoyer, dans un 1er temps, un couple login/password et de récupérer un token en retour. Dans un second temps, ce token devra être utilisé à la place du password pour les requêtes suivantes. Ceci permet, coté serveur, de gérer la durée de validité des tokens (à 20 minutes par exemple).

Mais ce qui me pose problème, c'est que en REST il n'y a pas d'état (Stateless). Comment est ce que le serveur peut identifier le token du client?, ceci impose de faire persisté le token généré par le serveur soit en base de donné ou en session, dans les deux cas on casse le principe de REST!

Pouvez vous m'aider svp?

[David55]

Bonjour,

Ceci impose de faire persisté le token généré par le serveur soit en base de donné ou en session

Oui effectivement, une session ca peut être bien.

on casse le principe de REST!

Quel principe? C'est l'homme qui crée les principes donc on peut bien les changer
Plus sérieusement, REST est un outil, il n'y a pas vraiment de contrainte. J'utilise des sessions dans mes WS et ca n'a jamais posé de problème à personne
Ce qui veut dire que si tu as besoin de session, utilises les sessions! Surtout s'il n'y a pas d'autre solution!!!

Liens intéressants : http://blog.nicolashachet.com/niveau...e-en-5-regles/
http://stackoverflow.com/questions/6...te-restfulness

[Rohan21]

Bonjour David55,

Je pensais que le serveur ne devais pas se soucier du contexte du client. Pourquoi on dit qu'il n'y a pas d'état dans REST?

Merci pour les liens, je vais les consulter
Cdt,

[nicroman]

En tant que fervant défenseur de REST... un web-service ne peut pas être REST si il n'est pas "Stateless" (donc sans session coté serveur)...
Il ressemblera à du REST, il aura le goût du REST, mais ne sera pas vraiment REST

Le token, ton serveur y met ce qu'il veut....

Token "decrypté": {salt}:{datevalidité}:{userid}:{hash}
Le salt étant par exemple une chaine aléatoire.
datevalidité ben la durée de validité du token.
userid l'identifiant interne (souvent un nombre) de l'utilisateur.
hash un code de hash de tout ce qui précède.

Ainsi à la réception d'une requête, il "suffit" de vérifier que le "hash" est correct, que la date de validité est bonne... et bim... le userid est autorisé et validé, sans même vérifier dans la table des utilisateurs.

On peut aussi rajouter d'autres informations comme l'@ IP de l'origine.
Vérifier que le salt s'incrémente à chaque requête (ainsi un nouveau token invalidera obligatoirement le précédent), etc...

[Rohan21]

Merci David 55 pour ta réponse et pour tous ces éléments.

[David55]

Merci Rohan21 de me remercier

Mais je pense que tu voulais plutot remercier Nicroman qui a donné une réponse tout de même plus juste