Clé(s) pour l'API des membres

La petite souris est passée gustavi.

Mais attendez, les clefs API ne sont-elles pas censés être attribués automatiquement suite à une demande de l'utilisateur, comme avec OAuth, par exemple ?

Ce n'est pas encore le cas aujourd'hui. Pour l'instant c'est fait manuellement.

J'ai remarqué ça, oui, mais c’est prévu ou pas ?

Yep, ZEP 39.

Salut,

J'ai jeté un rapide coup d’œil sur l'implémentation d'OAuth2 de ZdS et je me suis rendu compte que la documentation ne présentait que l'authentification via Resource Owner Password Credentials Grant. Les autres types d'autorisation de OAuth ne sont pas supportés ?

Le seul type d'autorisation présentait ici implique que le client demande à l'utilisateur ses identifiants. Le but premier de OAuth étant d'éviter cela, c'est quand même dommage de présenter que ce type d'autorisation dans la documentation.

J'ai aussi, par curiosité, regardé la bibliothéque Django OAuth Toolkit (le lien dans la documentation est d'ailleurs mort) et j'ai vu que les routes pour gérer les clients (ou applications) sont disponibles sur le site en production.

Voir http://zestedesavoir.com/oauth2/applications/.

La souris vient de passer dans ta boite au lettres.

Pour info,

Je ne peux plus maintenir ce topic (plus les accès qui vont bien), ça serait pas mal qu'un superuser puisse reprendre en charge les prochaines demandes de clé API.

Je suppose que victor et moi-même suivons ce topic et pourront y répondre. Merci firm1.

Dommage, car la souris qui passe, c'était quand même un sacré mythe!

J’avais une question à propos de l’API mais je n’ai pas trouvé de sujet plus adapté que celui-ci pour la poser : comment identifier un problème venant de l’expiration de l’access token ? Est-ce un code particulier, ou quel est le message d’erreur ? Je n’ai pas trouvé, ni dans le code de ZdS, ni dans celui de django-rest-framework.

Tu reçois une 401 ?

Je ne sais pas, je voulais prévoir le cas pour un script qui pourrait tourner en background pendant plus de 10h, et je pense que c’est plus simple de juste attendre qu’une requête soit refusé parce que le token a expiré que comparer le temps à celui donné par la requête sur /oauth2/token/.

Je vous dis l’erreur qui est retourné dans 10 heures, je fais le test.

Ca devrait être une 401 sauf si Django / l’API ne respecte pas les standards.

En règle générale, on gère le cas 401 dans le client. (on se relog)

Dans de très rares cas, on anticipe la récupération d’un nouveau token (via le refresh token OAuth) en amont, mais c’est vraiment pour des cas très particuliers.

Si ça peut servir à quelqu’un d’autre :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

⟩ http --json GET https://zestedesavoir.com/api/notifications/ \
    Authorization:'Bearer v13DCZ39H5nvxziiILuecZupIoUOvn'

HTTP/1.1 401 UNAUTHORIZED
Allow: GET, HEAD, OPTIONS
Connection: keep-alive
Content-Type: application/json
Date: Sun, 18 Dec 2016 21:49:49 GMT
Server: nginx
Transfer-Encoding: chunked
Vary: Accept, Cookie
WWW-Authenticate: Bearer realm="api"
X-Content-Type-Options: nosniff
X-Xss-Protection: 1

{
    "detail": "Informations d'authentification non fournies."
}

Je pourrais avoir une clé s’il vous plaît ? C’est tleb, ce compte est pour un projet qui utilise les MPs. J’aurai pu utiliser mon compte mais les MPs se seraient mélangés et c’est plus simple pour expérimenter. (Je garde le suspens sur le projet. )

Coucou ,

>_< Je peux en avoir une ? J’ai loupé la ditribution de Noël.