Discussion :

[fanfouer]

Bonsoir,

Je me lance dans l'uniformisation de tous mes API et autres moyens d'accès à ma base de données offerts à mes différentes applications clientes et mon choix s'est orienté vers une solution basée sur REST (et tout ce que ca implique).
Ce topic est ouvert dans la section Javascript car bon nombre de mes clients sont écris en Javascript, une fois qu'une solution à mon problème aura été trouvée, je pourrai sans peine la transposer ailleurs.

Je vois à peu près comment procéder pour implémenter le plus possible de recommandation REST tout en restant fonctionnel. Se pose maintenant la question de l'authentification. Vaste domaine.
En utilisant jQuery et son module AJAX, il est facile de faire des requêtes adoptant toutes les méthodes HTTP nécessaires.

Au cours de mes lectures, j'ai pu trouver des articles comme celui-ci: http://broadcast.oreilly.com/2009/12...ntication.html
Il y est fait un certain nombre de recommandations que je compte bien suivre.
REST préconisant des services sans état, on se passera d'ouvrir des sessions, notamment pour garder en mémoire une authentification d'utilisateur.
L'utilisation d'une clé (à l'image de ce que fait Google par exemple), donnée à chaque requête par le client me parait être une alternative raisonnable.

Ma question : comment réaliser la partie client?
L'auteur de l'article dont je donne le lien plus haut évoque un codage des paramètres de la requête dont la clé fait partie avant l'envoi au serveur.
Quelqu'un a-t-il déjà mis ça en place?

La clé en elle même, corrigez-moi si je me trompe, est envoyée par le champ Authorization HTTP et réceptionnée comme argument HTTP Digest par le serveur.
Est-il possible de fixer ce genre de champ avec jQuery?


Pour des questions de cuisine interne, il faudra que la clé comporte deux informations à mon sens : la clé en elle-même, ainsi qu'un identifiant de compte (pouvant correspondre à un compte machine -> pas d'interactivité pour la saisie d'un login/password sur web services).
Est-ce réalisable? Les exemples qu'on voit de clé d'API sont souvent des singletons servant à vérifier si la clé est autorisée ou pas. Dans mon cas c'est forcément attaché à une identité donc il faut le login pour la retrouver.

Si vous avez des idées pour l'envoi de la requête dans la partie Javascript, c'est avec grand plaisir.
Bonne soirée.

[le_chomeur]

Bonjour, je me permet de te répondre car j'ai eu la même chose a mettre en place , mais coté serveur , et je te conseil également de distinguer la partie javascript ( client ) de la partie serveur /!\

Le client rest ne pose pas de problème en soit a ce que j'ai pu comprendre et ton soucis est de gérer la sécurisation et l'authentification.

Pour ce faire il te suffit de rajouter dans les entêtes http de tes requètes rest, une clé qui te permettra de passer les valeurs souhaité ( id utilisateur par exemple + clé de sécurisation qui authentifie la requète )

que l'on utilise comme ceci :

Identification client => serveur
Serveur répond ok + renvois clé => client
Client authentifié + nouvelle requète + la clé => serveur vérifie la clé précédement envoyé.
serveur répond + NOUVELLE clé => client stocke cette nouvelle clé pour la prochaine requète

La clé change ainsi à chaque requète pour s'assurer que c'est bien ce client qui a effectué la requète.

par contre tout ceci se fait coté serveur

[fanfouer]

Bonjour le_chomeur, merci de ta réponse.

Bonjour, je me permet de te répondre car j'ai eu la même chose a mettre en place , mais coté serveur , et je te conseil également de distinguer la partie javascript ( client ) de la partie serveur /!\

Tout à fait, la séparation est bien effective.
Le cadre de mon étude est construit avec un serveur php/mysql (le plus basique) et un client en Javascript avec jQuery.

Le client rest ne pose pas de problème en soit a ce que j'ai pu comprendre et ton soucis est de gérer la sécurisation et l'authentification.

Oui c'est cela.

Pour ce faire il te suffit de rajouter dans les entêtes http de tes requètes rest, une clé qui te permettra de passer les valeurs souhaité ( id utilisateur par exemple + clé de sécurisation qui authentifie la requète )

que l'on utilise comme ceci :

Identification client => serveur
Serveur répond ok + renvois clé => client
Client authentifié + nouvelle requète + la clé => serveur vérifie la clé précédemment envoyé.
serveur répond + NOUVELLE clé => client stocke cette nouvelle clé pour la prochaine requête

La clé change ainsi à chaque requète pour s'assurer que c'est bien ce client qui a effectué la requête.

Je me représente bien le déroulement de la chose mais ça me pose certains problèmes.
Je vois mal comment gérer, en javascript, cette négociation en plusieurs temps avant la requête principale.
jQuery permet facilement d'utiliser des callbacks pour traiter la réponse du serveur, ce qui voudrait dire qu'il faut imbriquer autant de callbacks que le scénario comporte d'échanges avant de lancer cette requête principale?

De plus, le serveur donnant une nouvelle clé au client à chaque requête, il faut que chacun la conservent.
Pour le client je vois bien comment faire (c'est une instance de classe -> attribut privé), pour le serveur un peu moins. Utiliser une $_SESSION? Pour différencier tous les clients / accès concurrents...
Ne serait-ce pas un peu lourd?

Si on regarde le fonctionnement des services Amazon par exemple : http://docs.amazonwebservices.com/Am...on.html?r=1535
Le client dispose d'une clé fixe non actualisée à chaque requête.

Ca peut paraitre moins sécurisé (on vole la clé et le secret est éventé) mais en utilisant HTTP Digest + SSL pour faire les échanges ça règle la question.

En ayant réfléchi de mon côté : en implantant le realm et une clé fixe côté client, on peut envoyer une seule requête avec un header Authorization pour que le serveur authentifie, traite et renvoie le résultat en un seul échange.

Aurais-je oublié un détail?

[le_chomeur]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
En ayant réfléchi de mon côté : en implantant le realm et une clé fixe côté client, on peut envoyer une seule requête avec un header Authorization pour que le serveur authentifie, traite et renvoie le résultat en un seul échange.
 
Aurais-je oublié un détail?

Non tu peux également faire comme cela , mais n'oublie pas que les clé ne doivent jamais transité jusqu'à la partie client , donc garde les soit en base de données soit en session , mais surtout pas en clair dans la page client ( en js )

[fanfouer]

mais n'oublie pas que les clé ne doivent jamais transité jusqu'à la partie client , donc garde les soit en base de données soit en session , mais surtout pas en clair dans la page client ( en js )

Je n'ai pas compris ce passage.
Si la clé reste côté serveur, comment le client va-t-il faire pour envoyer une requête tout en étant authentifié?
Actuellement j'utilise bien des sessions sur mes services. l'application client, le client Javascript et le service sont sur le même sous-domaine donc lorsque l'utilisateur ouvre une session pour accéder au frontal elle est également visible sur les services.
C'est cependant un joli cas particulier et je veux en fini avec ça, plus de recours à la session sur le périmètre des services.

Dans le cas du Javascript (comme tout autre client Java, AS3...) je pensais créer un fichier contenant le realm, la clé et l'adresse du service que le client pourrait charger (en local pour du Java, AS3... ou depuis le serveur web pour JS) avant de faire ses requêtes.

Dans les cas de Google Maps, Amazon et j'en passe la clé est bien en dur sur le côté client non?

[le_chomeur]

Dans les cas de Google Maps, Amazon et j'en passe la clé est bien en dur sur le côté client non?

Je ne sais pas comment fonctionne leur système d'authentification donc je ne pourrais te répondre correctement a ce sujet , mais il y a une partie session/cookie oui

après je en connais pas plus les détails à leur sujet

[fanfouer]

mais il y a une partie session/cookie oui

C'est ce qui me dérange justement quand on veut faire du sans état

Si il ya cookie, la clé va bien jusqu'au client.

[le_chomeur]

oui mais en général elle est encodé donc peu de chance d'être volée à moins d'avoir accès directement au poste utilisateur ou d'utiliser d'autre moyen bien plus complexe