Discussion :

[jm54_]

Bonjour à tous,
j'ai une application web qui tourne très bien avec Django, c'est d'ailleurs plus un poc qu'une application utilisable en prod.
Ce que je voudrais, c'est de faire de ce poc une API rest, qui serait intérogée :
- soit par le site front qui tournera avec angularjs
- soit par une application mobile
- soit par un client lourd
- soit par un terminal
- soit par ...
...

dans l'idée, pas de soucis, avec DJango ca marche très bien, je vais donc utiliser django-rest pour l'interfacage.

Le probleme vient plutot de l'authentification. Avec Django tout va bien, tout se passe en HTTP, generic views toussa.
Avec django-rest, la doc nous amene plein d'authentification possibles, Session, Token, OAuth ...

Question 1: Quel est la meilleur solution à adopter ?
Ma réponse. Dans la mesure ou l'API est disponible via des clients différents, avec des contexts différents, l'utilisation de tokens me semblent plus qu'adaptées et vu que oauth2 est (toujours selon la doc) plus secure que les TokenSession, alors partons sur oauth2

Question 2: comment qu'on fait ?
Le probleme est bien la. J'ai beau lire la doc django-rest, celle de oauth, des exemples, la pour le coup je cale rien.

Ex: j'ai un user qui a un compte chez moi: c'est Jean.

Jean est sur le site, il a sa fenêtre de connexion, il renseigne son login et son mdp il valide et la, .... Il se passe quoi ? On envoie quoi et ou ? Le serveur retourne quoi ? Des fois je lis qu'il faut utiliser la methode login() de Django, des fois je lis qu'il faut implémenter du custom ...
Une fois Jean loggué, il requete l'API. Je suppose donc que l'on doit y mettre les token que le serveur nous a renvoyé un moment dans les headers, c'est ca ?

Ca c'est pour le scenario ou Jean est sur son browser. Imaginons maintenant qu'il requete l'API avec sont terminal et curl. Ca se passe comment ?

Voila désolé, c'est un beau pavé mais je suis vraiment embété la

Merci de votre aide.

[wiztricks]

Le probleme vient plutot de l'authentification. Avec Django tout va bien, tout se passe en HTTP, generic views toussa.

Avec une API tout est HTTP aussi, non?

Une fois Jean loggué, il requete l'API. Je suppose donc que l'on doit y mettre les token que le serveur nous a renvoyé un moment dans les headers, c'est ca ?

REST étant 'stateless', authentifier chaque requête n'est possible qu'en ajoutant des informations dans les headers.
Dire "Jean loggué" est une notion 'statefull'.

Question 2: comment qu'on fait ?
Le probleme est bien la. J'ai beau lire la doc django-rest, celle de oauth, des exemples, la pour le coup je cale rien.

Django est un framework utilise pour faire des sites Web et des applications Web. Autrement dit l'interface utilisateur sera le navigateur: la requete HTTP retourne (en general) un document HTML.
Une API REST est un protocole RPC construit sur HTTP permettant d’échanger (en général) des messages JSON ou XLM.
Cote infrastructure a mettre en œuvre, il y a beaucoup de similitudes et c'est ce qui permet de réaliser une extension django-rest.
Mais cote philosophie et design, cette cohabitation n'aide pas a comprendre que ce sont 2 mondes complètements différents.

- W

[jm54_]

merci pour la réponse.
Passé la théorie, je cherche des réponses précises quand à la mise en place de oauth2.

Jean est sur le site, il a sa fenêtre de connexion, il renseigne son login et son mdp il valide et la, .... Il se passe quoi ? On envoie quoi et ou ? Le serveur retourne quoi ? Des fois je lis qu'il faut utiliser la methode login() de Django, des fois je lis qu'il faut implémenter du custom ...

Merci

[wiztricks]

Jean est sur le site, il a sa fenêtre de connexion, il renseigne son login et son mdp il valide et la, .... Il se passe quoi ? On envoie quoi et ou ? Le serveur retourne quoi ?

Cela fait une requete HTTP equivalente comme le dit documentation:

Code :

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

curl -X POST -d "client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=password&username=YOUR_USERNAME&password=YOUR_PASSWORD" http://localhost:8000/oauth2/access_token/

Le serveur doit retourner un JSON:

Code :

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

{"access_token": "<your-access-token>", "scope": "read", "expires_in": 86399, "refresh_token": "<your-refresh-token>"}

Django n'a pas le choix: il ne fait qu’implémenter le "standard" OAUTH2 du RFC 6749. Ce que vous lisez dans la doc sont des cut&paste ou des renvois de ce standard.

Si vous voulez "voir" ces échanges, vous pouvez faire une capture des packets avec un outil comme Wireshark.

- W

[jm54_]

Merci wiztricks !

en fait je crois que j'ai un probleme avec la notion de client.

Voila ce que je vois/comprends.
Jean est le resource owner.
Il utilise 2 clients:
- son navigateur sur foo.com qui est une application angularjs
- un client lourd java

api.foo.com est le resource server. C'est un Django / django-rest.
oauth2 gère l'authentication.
Les autorisations sont gérées par django/django-rest

Si Jean veut voir le contenu des voitures sur foo.com/#cars, il faut qu'il soit loggué.
Il a donc crée un compte ou on lui a demandé son email et un mot de passe.
Le compte est validé, il peut donc se connecter avec ces même login/mdp.
Au moment ou une fois loggué, il va sur foo.com/#cars/, une requete est faite sur api.foo.com/cars/ qui retourne la liste des voitures sous un format JSON.

Voila comment je vois les chose et je pense ne pas beaucoup me tromper.
La ou j'ai du mal c'est pour la partie 'client' donc. La doc django-rest nous dit que l'on doit créer un cient

Code :

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

You can create a client, either through the shell, or by using the Django admin.

Seulement si y'a 1000 utlisateurs qui passent par leur navigateurs, les 1000 vont avoir le meme client_id ?? Je ne crois pas. On a donc 1000 clients différents. Quand ces clients sont-ils alors créés ? Au moment ou Jean à fait son inscription sur le site foo.com ?
Idem pour le client java, Jean doit demander la creation d'un client sur la plateforme avant de pouvoir avoir la liste des voitures ?


C'est incroyable vraiment j'ai du mal avec tout ca mais comme on dit il n'y a pas de questions bêtes

[wiztricks]

Il a donc crée un compte ou on lui a demandé son email et un mot de passe.
Le compte est validé, il peut donc se connecter avec ces même login/mdp.
Au moment ou une fois loggué, il va sur foo.com/#cars/, une requete est faite sur api.foo.com/cars/ qui retourne la liste des voitures sous un format JSON.

Ah je crois comprendre.
Vous allez a l'URL du RFC.
Vous cherchez "[Page 10]".
A la suite, une sorte de diagramme de séquence montre les différences entre:
- l'utilisateur qu'on enregistre dans une BDD,
- la négociation du token avec le serveur de token,
- son utilisation pour accéder aux ressources,

C'est incroyable vraiment j'ai du mal avec tout ca mais comme on dit il n'y a pas de questions bêtes

*FLAME ON*
Des frameworks comme Django permettent de réaliser rapidement une application Web en gardant le focus sur le fonctionnel et en proposant du prêt a l'emploi pour ce qui est configuration, déploiement,...
L'avantage est de ne pas avoir a refaire des trucs fastidieux et répétitifs.

Réduire le temps de codage a l'avantage de pouvoir le faire réaliser par un ingénieur. On le paiera plus "cher" moins longtemps. Cette polyvalence permettra de l'employer "plus" sur la durée du projet.
Cela permet aussi de réduire le nombre de personnes: moins de pertes d'informations, plus de cohérence cote livrables, ...

Sans "framework", on devrait diviser le travail entre conception et réalisation et embaucher des "codeurs" payes moins cher mais plus longtemps.

En masquant la complexité des piles techniques, on permet aussi a un stagiaire de construire un serveur Web sans trop savoir ce qui se passe sous le capot. Ce qui fait le site Web encore moins cher.

Et de pauvres bougres mendiant des réponses a des questions qu'ils ne savent pas poser dans les forums.
note: ce que je pense n'a rien de personnel.
*FLAME OFF*

Bonne continuation.
- W

[jm54_]

l'interet de ce gout de gueule est il légitime ? A mon sens non, il y a une différence entre se documenter et comprendre.
Je partage votre avis sur les framework et sur les méthodes de ventes de solutions orchestrées par beaucoup d'agences.
Maintenant je pense aussi que les forums sont des lieux d'échanges et que d'autres personnes se poseront sans doute les memes questions que moi sans oser demander.

[gorjuce]

je ne comprends pas non l'interet de la réponse wiztricks, si c'est pour répondre RTFM autant ne rien dire.

[wiztricks]

je ne comprends pas non l'interet de la réponse wiztricks, si c'est pour répondre RTFM autant ne rien dire.

Ben ouais mais les réponses aux questions posées sont a la page 10 du RFC et je ne vois pas trop l’intérêt d'un "cut&paste".

La sécurité est un sujet sérieux qui engage votre responsabilité.
Si vous n’êtes pas assez a l'aise sur ces questions, faites faire plutôt que de faire courir le risque d'un n'importe quoi a votre employeur ou a vos clients.

- W

[jm54_]

Aucun débat à avoir, tout le monde doit apprend à marcher un jour. Maintenant des questions ont été posées, vous n'avez pu apporter aucune réponse, je note donc que l'enseignement n'est pas votre qualité principale.

[wiztricks]

La sécurité est un sujet trop important pour qu'on s'amuse a construire une solution a votre place. Faites faire ou ayez la patience d'apprendre est le seul choix raisonnable qu'un professionnel puisse vous proposer.

C'est ma position.
Ceci dit, elle n'engage que moi.
D'autres pourront exprimer un avis différent.

- W