bonjour, je voudrais savoir comment generer un token tous les minutes en python ? sur un server qui s’execute (j’utilise flask)? peut etre il faut utiliser ascyn http de python ?
merci pour votre attention
Bonjour,
Désolé mais ta question n’a pas de sens comme ça. Pourquoi tu veux un token ? C’est quoi ton problème à la base ?
en faite c’est pas toute les minutes on vas dire toute les jours , c’est pour authentification dans une api ,
Humm, tu veux pas un JWT ?
Bon ça ne change pas grand chose. Le principe est à peu près le même. Grosso modo, tu crées un jeton (ou token) que tu associes à une date de validité (qui peu être infinie).
Ensuite, tu stockes la correspondance entre jeton, utilisateur et date de validité dans une BDD et puis c’est bon. Donc si je comprends bien tu veux un jeton avec une date de validité d’un jour ?
Je vois le tag thread ? Où bloques-tu exactement ? Pourquoi parles-tu de fils d’exécution ?
bon merci je regarderai jwt , au debut j’avais un truc qui utilise threading.Timer mais le probleme quand le token expirais il fait en regener et donc faire un nouveau thread ca me fesait cet erreur:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/threading.py", line 1009, in _bootstrap_inner
v0BpGJpGqXlDgfXlg4GAl4R6Dluzd-4Vkd6toZX22S6p8wIdC-OSUg
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x00007f8033704470)
Current thread 0x000000010b460600 (most recent call first):
<no Python frame>
donc en faite je vais finalement pas l’utiliser et utiliser jwt
Encore une fois, tu nous exposes un sous problème du problème global et pas le problème réel. Du coup, la solution JWT n’est pas forcément adapté, tout dépend du problème.
bon, ok voila je voulais faire un python rpc pff mon plan devoile 
donc le client doit donner un bon token pour s’authentifier
Légèrement HS mais pas tant que ça :
Ensuite, tu stockes la correspondance entre jeton, utilisateur et date de validité dans une BDD et puis c’est bon.
Je ne vois pas pourquoi il y aurait besoin de stocker cette correspondance dans une BDD, dès lors que ces informations (dates de validité — début de validité et expiration — et au moins l’id de l’utilisateur) sont embarquées dans le JWT et que celui-ci est signé cryptographiquement.
Au contraire, les stocker dans une BDD me semble peindre une grosse cible en rouge sur cette BDD pour d’éventuels attaquants désireux d’usurper l’identité des utilisateurs…
Du moment que l’algo utilisé pour signer le token est fiable (et que le transport sur le réseau est chiffré), il suffit de vérifier la signature pour s’assurer de l’authenticité des informations embarquées d’une part, et du fait que le jeton a été signé par "nous" ou en tout cas par l’acteur responsable d’authentifier le porteur.
C’est exactement ce qui se passe quand on vérifie un token provenant d’un fournisseur d’identité tiers comme google/apple/facebook/… en utilisant le protocole openid connect : on vérifie la signature du JWT en utilisant la clé publique du provider, ainsi que les claims embarqués dedans comme sa période de validité, le fait qu’il a bien été généré pour notre application ("audience"), par le provider lui-même ("issuer"), etc.
Cela m’amène au problème de ce topic : ok il est donc question de faire de l’authentification, mais je ne vois pas du tout pourquoi il y aurait besoin de générer un token automatiquement à intervalles réguliers.
En général, on fournit un token avec une date d’expiration, et on dispose d’un point d’accès qui permet de rafraîchir ce token, en laissant la responsabilité au client de rafraîchir régulièrement son token pour rester authentifié.
Du coup ce que l’on attend de toi @NightProg c’est que tu nous décrives comment fonctionne ton système d’auth afin de comprendre dans quel contexte tu peux avoir besoin de générer périodiquement des tokens aléatoires… Parce que dit comme ça, ça semble louche.
Légèrement HS mais pas tant que ça :
Ensuite, tu stockes la correspondance entre jeton, utilisateur et date de validité dans une BDD et puis c’est bon.
Je ne vois pas pourquoi il y aurait besoin de stocker cette correspondance dans une BDD, dès lors que ces informations (dates de validité — début de validité et expiration — et au moins l’id de l’utilisateur) sont embarquées dans le JWT et que celui-ci est signé cryptographiquement.
Je décrivais le fonctionnement d’un jeton classique ! Pas de JWT. Ça ne colle pas du tout avec le fonctionnement de JWT, j’ai juste vérifié qu’il ne voulait pas un jeton JWT.
Mais je ne comprend toujours pas pourquoi l’OP veut utiliser les threads, qui devraient être utilisé par requêtes, éventuellement, mais pas spécifiquement pour la génération des jetons.
bon merci je regarderai jwt , au debut j’avais un truc qui utilise threading.Timer mais le probleme quand le token expirais il fait en regener et donc faire un nouveau thread ca me fesait cet erreur:
Mais là par exemple, je ne comprend pas pourquoi il y a une option spéciale pour régénérer.
Je décrivais le fonctionnement d’un jeton classique !
Au temps pour moi, la façon dont ton post est tourné le laissait à penser.
J’ai l’impression que l’OP mélange plusieurs problèmes. En particulier, qu’il cherche un moyen de déclencher une action à intervalles réguliers de façon concurrente avec le fil d’exécution principal… Alors qu’il n’en a pas besoin à la base.
Ça ressemble assez fort à un cas de XY problem.
En particulier, qu’il cherche un moyen de déclencher une action à intervalles réguliers de façon concurrente avec le fil d’exécution principal
oui bon, imaginons qu’un client veut envoyer un script python pour qu’il s’execute sur le server, il va utiliser pyscmd (ma lib) mais il faut aussi que pyscmd soit installe sur le server et donc pendant l’installation pyscmd genera un token et c’est ce token qui va se regenerer tous les jours/mois pour s’authentifier
Ok, alors là je comprends encore moins la pertinence d’utiliser des tokens tout court, plutôt que la même chose que des systèmes déjà existants comme SSH (avec un échange de clés). Ou même (à la fois plus facile et bien plus sécurisant), de carrément de déléguer l’auth au transport réseau en reposant directement sur SSH comme le fait par exemple rpyc.
Vraiment, fais l’effort de développer ce que tu cherches à faire : explique-moi comme si j’avais 5 ans ou comme si c’était à moi de le coder, comment fonctionnerait ton authentification ?
D’une façon générale, créer un système d’authentification "maison" est presque toujours une très mauvaise idée. Pour tout ce qui touche à la sécurité, il est systématiquement préférable d’utiliser des standards et de outils existants lorsque c’est possible.
Ne regénère pas un token automatiquement. Normalement, un token est lié à une date de validité. Elle n’est pas sencé être extensible.
À la fin de la date de validité, le client doit se ré-authentifier.
Sinon tu perds l’intérêt d’une date de validité.
D’une façon générale, créer un système d’authentification "maison" est presque toujours une très mauvaise idée. Pour tout ce qui touche à la sécurité, il est systématiquement préférable d’utiliser des standards et de outils existants lorsque c’est possible.
Un énorme +1 à ceci. C’est déjà assez compliqué de faire fonctionner un système d’authentification bien connu et sécurisé sans casser sa sécurité. Improviser quelque chose hors des standards, c’est la garantie d’obtenir une « sécurité » complètement cassée.
D’autre part :
@NightProg, pourrais-tu préciser de quel genre de tokens tu parles et de comment tu les utilises ? En lisant ta question, j’ai l’impression que tu parles de tokens OAuth2.0 (ou similaires) mais j’ai peut-être mal compris.
oui , je croie que oui pour auth2.0
À la fin de la date de validité, le client doit se ré-authentifier.
oui, je me suis tres mal exprime
Ou même (à la fois plus facile et bien plus sécurisant), de carrément de déléguer l’auth au transport réseau en reposant directement sur SSH comme le fait par exemple rpyc.
interresant 
Vraiment, fais l’effort de développer ce que tu cherches à faire : explique-moi comme si j’avais 5 ans ou comme si c’était à moi de le coder, comment fonctionnerait ton authentification ?
bon, meme moi c’est confus pour ce que je cherche , je voulais une technique pour etre sur que le client a les pouvoirs nécessaire pour acceder un server
Ca tombe bien, on a un tutoriel sur OAuth 2.0.
Et en effet, dans ce cas, il est nécessaire de rafraichir son token de temps en temps. Soit tu fais ça de façon planifiée (comme tu le mentionnais plus tôt avec ton Timer), soit tu le fais à la demande (quand un utilisateur veut utiliser un token et tu remarques qu’il est expiré, tu le rafraichis d’abord avant de l’utiliser). En fonction du type d’utilisation auquel tu t’attends, une approche peut être plus appropriée que l’autre.
super , a zds a tout 
Soit tu fais ça de façon planifiée (comme tu le mentionnais plus tôt avec ton Timer)
ah probleme quand le token expirai , il faut donc le regenerer alors un nouveau thread apparait qui va s’expirer etc alors python se crash du au nombre important de thread que j’ai creer
une autre chose ou stocker ce token parce que par example si tu le stockes quelque part dans le server et si malheuresement un program malveillant arrive a le lire alors il peut executer du code a distance , don cfaut il le crypter ?
ah probleme quand le token expirai , il faut donc le regenerer alors un nouveau thread apparait qui va s’expirer etc alors python se crash du au nombre important de thread que j’ai creer
Tu n’as pas besoin d’un thread par token. Si tu sais que les tokens sont valides pendant 1 jour, tu peux lancer un thread par jour qui va tous les rafraichir.
une autre chose ou stocker ce token parce que par example si tu le stockes quelque part dans le server
Une fois encore, ça dépend de ton utilisation et de quand/dans quel contexte tu utilises le token. Si sa durée de vie n’est que de quelques minutes, tu ne le stockeras pas en base de données mais tu stockeras uniquement le refresh_token. Mais oui, le chiffrer peut être une bonne idée. Aussi, il est important de ne demander que les accès nécessaires au bon fonctionnement de ton token. Si ton application ne fait que lire des données, rien ne sert de demander des droits en écriture. Ainsi, si le token fuite, le hacker n’obtiendra que des droits limités.
et si malheuresement un program malveillant arrive a le lire alors il peut executer du code a distance
Je ne vois pas ce que tu veux dire ici.
en faite ma lib que je veux creer permet d’executer du code python a distance donc si il a le token il peux executer du code python a distance
en faite ma lib que je veux creer permet d’executer du code python a distance donc si il a le token il peux executer du code python a distance
Pas sûr que ce soit une si bonne idée…
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte