J'ai aussi flake8/pylint qui s'exécutent dans mon éditeur (et chez moi, c'est mieux, c'est vim) et ce depuis longtemps, donc je code propre "naturellement" par habitude. Mais avec black, je m'emmerde même plus à corriger certains trucs parce que je sais que ça se fera tout seul.
J'ai appris énormément en contribuant à umongo puis marshmallow et consorts. Ça m'a permis d'injecter des bonnes pratiques (CI, etc.) dans les projets au boulot. Mieux qu'une formation. C'est comme ça que je suis devenu mainteneur.
Mais ça marchait parce que j'avais besoin de fonctionnalités, puis j'y ai pris goût et je fais des choses donc je n'ai pas besoin directement. Mais si je ne suis plus utilisateur, je n'ai plus d'intérêt à y passer du temps.
J'ai déjà vu quelqu'un sur GitHub qui cherchait à contribuer pour contribuer, pour ajouter des lignes à son profil. Il proposait des modifs inutiles ou sans grand intérêt et il fallait le prendre par la main pour faire sa pull-request parce qu'il comprenait rien au process de développement du projet. Au final ça fait plus perdre de temps au mainteneur qu'autre chose.
J'ai compris que dans ton cas c'est pas tout à fait l'idée, mais je plussois quand-même le conseil. Contribue à un projet que tu trouves utile.
Il y a quelques logiciels utilisateur final en Python dans nos environnement. Logiciel de recherche de fichiers, lecteur multimédia, etc.
Je m'étais cassé la tête à trouver des solutions pour faire de l'autorisation avec des périmètres, pas juste du RBAC (un utilisateur peut lire les documents), mais la possibilité par exemple de dire qu'un utilisateur peut lire les documents qui sont dans son groupe.
J'avais rien trouvé d'utile. Pour le RBAC, il y a du monde, mais dès qu'il y a en plus du relationnel, c'est tout de suite métier et on trouve pas de code générique.
Oso est arrivé à pic. La partie relationnelle est bien abstraite. Pour l'instant je suis assez bluffé.
Ça me revient, en effet, c'est avec toi que j'avais échangé sur apispec que vous utilisez dans Hapic. Ca remonte un peu et on avait un gros refactor en cours sur apispec. C'est plus calme maintenant. C'est vrai aussi pour webargs et marshmallow.
Anéfé, j'avais pas vu la précision en bas et tiqué sur la formulation en haut.
J'ai pas d'autre exemple courant. On doit pouvoir décorer une variable dans un module, un attribut dans une classe,… mais c'est pas quelque chose que je fais couramment.
Je bosse sur des environnements un peu similaires mais synchrones. Dans nos projets, on utilise flask-smorest, framework basé marshmallow, apispec, webargs. Il me semble que vous l'utilis(i|)ez aussi, j'avais eu des discussions avec des gens de chez vous sur Github. Et on utilise de plus en plus SQLAlchemy.
Au début j'ai utilisé flask-sqlalchemy mais je l'ai viré rapidement pour faire les quelques lignes de codes qui suffisaient. De mémoire, il apportait pas grand-chose et me gênait si je voulais accéder à la base sans passer par flask. En gros, c'était trop raccourci et j'étais plus à l'aise à faire un code que je comprenais. J'utilise scoped_session, et j'ai une classe qui reproduit une interface similaire à flask-sqlalchemy, avec une instance de db globale (créée à l'import) qui traîne partout dans le code et dont j'initialise l'accès à la base à l'init de l'application.
J'utilise souvent le combo ContextVar / ContextManager, en particulier pour passer des sessions. Je l'ai fait dans umongo (MongoDB ODM basé marshmallow) pour pouvoir faire des transactions sans passer la session via toute la pile de fonctions. Dans l'app sur laquelle je bosse en ce moment, j'ai une ContextVar CURRENT_USER que je renseigne dans le décorateur qui authentifie chaque route de l'app et que je lis dans la couche qui gère les permissions. Le coeur du code, qui contient la couche permissions, expose donc un context manager qui permet de renseigner l'utilisateur, et c'est ce context manager que j'utilise dans l'app.
Au passage, pour les permissions, j'ai utilisé Oso que j'ai découvert via le blog de StackOverflow et j'ai trouvé ça franchement pratique. Bien mieux que le code spaghetti maison que j'avais fait avant. Pour la peine, je viens de poster un lien ici.
Il y a un pain avec le formattage de code de ton article, après "Pour les curieux, voici la partie du code transmettant le contexte aux threads".
J'ai acheté 30€ un mixeur Magimix (basique) d'occasion et j'ai revenu les pièces de mon mixeur cassé (les bols, les lames,…). Grâce à ça je pense avoir "sauvé" 4 ou 5 mixeurs et en plus j'ai récupéré à peu près 30€. C'est un peu pénible à faire mais je ne regrette pas l'opération.
C'est possible que les fichiers de config utilisateur des différents logiciels soient mal reconnus.
Si le logiciel est distribué différemment et le fichier n'est pas au même endroit ou pas au même format. Peu probable.
Si la version de logiciel est différente sur Debian, en particulier si elle est plus ancienne (si elle est plus récente, la transition doit se faire toute seule). Avec une Debian récente, c'est assez peu probable aussi.
Au pire, ça doit être marginal, mais le problème existe en théorie.
Je peux récupérer les .fit en mass storage. Un autre commentaire ici indique un outil pour en faire du GPX.
Je peux charger des GPX en mass storage. Il faut les mettre dans le dossier "NEWFILES" et ensuite la montre se débrouille. J'ai trouvé l'info au détour d'un forum, c'était pas dans la doc. Content de pouvoir écrire ça ici pour la postérité francophone.
J'ai vue une revue de la montre qui disait que l'appli était super nécessaire à l'utilisation. Franchement, je trouve pas. C'est nécessaire pour la customisation des objectifs quotidiens (que j'utilise pas) mais pour le reste (définition des entraînements, customisation des écrans) j'ai jamais été bloqué.
Mais que celui qui se fait usurpé soit puni, c'est juste que Cédric O s'est embrouillé.
Sa phrase est pourtant assez claire. Il menace les gens qui prêtent leur pass. Mais c'est peut-être encore une phrase balancée comme ça sans réfléchir à la faisabilité.
Les restaurateurs et commerçants sont déjà un peu réticents à faire les flics à l'entrée de leurs établissements. C'est une chose de se résigner à contrôler, c'en est une autre de leur demander en plus de dénoncer les fraudeurs.
Conclusion provisoire – 22/06/2021
Si tous les établissements bancaires respectent leur engagement d'alternative et rendent rapidement utilisable le SMS renforcé, alors l'obligation d'utiliser une application mobile disparait.
Et le problème n'est plus (ce qui n'empêche pas qu'il y en ait d'autres).
Reste que ça repose sur un SMS donc une ligne mobile, pour une consultation de comptes ou un achat qui ne nécessite qu'internet. (Avec alternative potentielle à base de dispositif physique unique type lecteur de carte CB générateur de code.)
La solution mise en place par PayPal décrite dans mon commentaire ici me paraitrait utile comme troisième possibilité.
A noter qu'une appli OTP ça peut tourner sur un ordi, une tablette, un vieux smartphone récupéré qu'on n'utilise qu'en WIFI, donc ça n'impose pas un smartphone + un abonnement.
Pour bosser un fichier de traitement de texte, il y a une logique à le faire en local plutôt que le charger dans le cloud et bosser dans un navigateur : confidentialité, performance de l'IHM. Même s'il y a des fonctionnalités pertinentes dans le cloud : rédaction à plusieurs. L'information est naturellement présente côté client.
A l'inverse, pour lire des infos sur un site web, l'info est naturellement présente côté serveur, et le web est un standard qui permet à chacun d'y avoir accès sans préjuger de quoi que ce soit (ou presque), et c'est mieux d'un point de vue interopérabilité, confidentialité, etc. En contrepartie, il peut y avoir un léger gain en IHM à passer par une appli dédiée, surtout sur un smartphone.
Enfin on est sur DLFP, quand-même, donc ne pas perdre de vue client libre vs. appli proprio.
Weboob, par ailleurs, ça sert à sortir du browser, mais pas pour enferme l'utilisateur, justement pour lui permettre d'automatiser ou de faire à sa sauce des choses qu'il peut faire parce qu'il s'appuie sur le web (faute d'avoir une vraie API vraiment ouverte).
Si tous les établissements bancaires respectent leur engagement d'alternative et rendent rapidement utilisable le SMS renforcé, alors l'obligation d'utiliser une application mobile disparait.
Et le problème n'est plus (ce qui n'empêche pas qu'il y en ait d'autres).
Reste que ça repose sur un SMS donc une ligne mobile, pour une consultation de comptes ou un achat qui ne nécessite qu'internet. (Avec alternative potentielle à base de dispositif physique unique type lecteur de carte CB générateur de code.)
La solution mise en place par PayPal décrite dans mon commentaire ici me paraitrait utile comme troisième possibilité.
A noter qu'une appli OTP ça peut tourner sur un ordi, une tablette, un vieux smartphone récupéré qu'on n'utilise qu'en WIFI, donc ça n'impose pas un smartphone + un abonnement.
un mot de passe temporaire (OTP: one time password)
Le principe c'est qu'une fois connecté à mon compte PayPal j'ai demandé la génération d'un code (8 chiffres) affiché uniquement lors de sa génération, une sorte de token, que je renseigne dans mon générateur d'OTP (un logiciel libre mais on peut aussi utiliser Google Authenticator si on y tient ou si ça fait plus sexy).
Ça doit être plus ou moins équivalent au boîtier dans lequel on insère la CB pour générer des codes sauf que c'est pas la détention de la CB et la connaissance de son code qui font foi mais la connaissance du code initial à 8 chiffres qui a servi à initialiser l'appli OTP.
Pas besoin de smartphone ni de téléphone tout court ni de boîtier. Il faut juste avoir un dispositif avec un générateur d'OTP initialisé avec le code. Ça peut être un smartphone, auquel cas c'est déjà mieux puisqu'on a pas besoin de l'appli de la banque (mais peut-être que la banque préfère "imposer" son appli ?). Ça peut être l'ordi de la maison et celui du boulot. Bref, c'est un poil plus souple que le boîtier. Ça peut même être installé sur un serveur perso pour être accessible de n'importe-où même si c'est un peu plus sioux.
J'imaginais que c'était conforme DSP2 et que les banques pourraient faire pareil.
Pas sûr qu'on en prenne le chemin. A La Poste ils veulent à tout prix imposer l'appli (donc le smartphone) à tout le monde pour accéder à ses comptes.
Je crains le jour où le web ne servira plus qu'à aller lire DLFP, pour le reste il faudra des applis de smartphone privatrices.
Je prendrais probablement pas le temps de creuser. Je n'utilise Chromium qu'épisodiquement, si j'ai une difficulté avec Firefox, ou pour tester le rendu d'un dev.
Si je comprends bien, Debian fait déjà un peu le boulot, c'est déjà ça.
[^] # Re: Python black
Posté par jihele . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 4.
J'ai aussi flake8/pylint qui s'exécutent dans mon éditeur (et chez moi, c'est mieux, c'est vim) et ce depuis longtemps, donc je code propre "naturellement" par habitude. Mais avec black, je m'emmerde même plus à corriger certains trucs parce que je sais que ça se fera tout seul.
[^] # Re: ton besoin ?
Posté par jihele . En réponse au message trouver de bons projets open source. Évalué à 3.
Absolument.
J'ai appris énormément en contribuant à umongo puis marshmallow et consorts. Ça m'a permis d'injecter des bonnes pratiques (CI, etc.) dans les projets au boulot. Mieux qu'une formation. C'est comme ça que je suis devenu mainteneur.
Mais ça marchait parce que j'avais besoin de fonctionnalités, puis j'y ai pris goût et je fais des choses donc je n'ai pas besoin directement. Mais si je ne suis plus utilisateur, je n'ai plus d'intérêt à y passer du temps.
J'ai déjà vu quelqu'un sur GitHub qui cherchait à contribuer pour contribuer, pour ajouter des lignes à son profil. Il proposait des modifs inutiles ou sans grand intérêt et il fallait le prendre par la main pour faire sa pull-request parce qu'il comprenait rien au process de développement du projet. Au final ça fait plus perdre de temps au mainteneur qu'autre chose.
J'ai compris que dans ton cas c'est pas tout à fait l'idée, mais je plussois quand-même le conseil. Contribue à un projet que tu trouves utile.
Il y a quelques logiciels utilisateur final en Python dans nos environnement. Logiciel de recherche de fichiers, lecteur multimédia, etc.
# Python black
Posté par jihele . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 6.
En Python, on a black. Je l'utilise avec pre-commit pour formater le code avant de commiter.
Au début, j'étais un peu gêné par certains choix, mais à l'usage, je trouve que le bénéfice en vaut la peine.
Je n'ai plus besoin de fignoler le formatage pendant que je code, je laisse les choses vaguement propres et au commit black met tout au carré.
Je l'ai utilisé trois jours et quand je l'ai plus, ça me gêne.
[^] # Re: Contextvars rulz et autres considérations
Posté par jihele . En réponse au lien FastAPI et SQLAlchemy – en asynchrone, attention aux faux amis. Évalué à 3.
Je m'étais cassé la tête à trouver des solutions pour faire de l'autorisation avec des périmètres, pas juste du RBAC (un utilisateur peut lire les documents), mais la possibilité par exemple de dire qu'un utilisateur peut lire les documents qui sont dans son groupe.
J'avais rien trouvé d'utile. Pour le RBAC, il y a du monde, mais dès qu'il y a en plus du relationnel, c'est tout de suite métier et on trouve pas de code générique.
Oso est arrivé à pic. La partie relationnelle est bien abstraite. Pour l'instant je suis assez bluffé.
[^] # Re: Contextvars rulz et autres considérations
Posté par jihele . En réponse au lien FastAPI et SQLAlchemy – en asynchrone, attention aux faux amis. Évalué à 2.
Ça me revient, en effet, c'est avec toi que j'avais échangé sur apispec que vous utilisez dans Hapic. Ca remonte un peu et on avait un gros refactor en cours sur apispec. C'est plus calme maintenant. C'est vrai aussi pour webargs et marshmallow.
[^] # Re: décorateur
Posté par jihele . En réponse au message a quoi sert @?. Évalué à 2.
Anéfé, j'avais pas vu la précision en bas et tiqué sur la formulation en haut.
J'ai pas d'autre exemple courant. On doit pouvoir décorer une variable dans un module, un attribut dans une classe,… mais c'est pas quelque chose que je fais couramment.
[^] # Re: décorateur
Posté par jihele . En réponse au message a quoi sert @?. Évalué à 2.
N'importe quel objet, pas forcément une fonction.
C'est aussi souvent une classe, par exemple.
[^] # Re: Les langages supportés, la licence
Posté par jihele . En réponse au lien Oso - Cadriciel de gestion de rôles et de permissions. Évalué à 4.
Merci. Ça aurait mérité un journal, mais j'ai pas pris le temps et j'attends d'avoir un peu plus joué avec.
# Contextvars rulz et autres considérations
Posté par jihele . En réponse au lien FastAPI et SQLAlchemy – en asynchrone, attention aux faux amis. Évalué à 4. Dernière modification le 26 novembre 2021 à 18:46.
Salut.
Je bosse sur des environnements un peu similaires mais synchrones. Dans nos projets, on utilise flask-smorest, framework basé marshmallow, apispec, webargs. Il me semble que vous l'utilis(i|)ez aussi, j'avais eu des discussions avec des gens de chez vous sur Github. Et on utilise de plus en plus SQLAlchemy.
Au début j'ai utilisé flask-sqlalchemy mais je l'ai viré rapidement pour faire les quelques lignes de codes qui suffisaient. De mémoire, il apportait pas grand-chose et me gênait si je voulais accéder à la base sans passer par flask. En gros, c'était trop raccourci et j'étais plus à l'aise à faire un code que je comprenais. J'utilise scoped_session, et j'ai une classe qui reproduit une interface similaire à flask-sqlalchemy, avec une instance de db globale (créée à l'import) qui traîne partout dans le code et dont j'initialise l'accès à la base à l'init de l'application.
J'utilise souvent le combo ContextVar / ContextManager, en particulier pour passer des sessions. Je l'ai fait dans umongo (MongoDB ODM basé marshmallow) pour pouvoir faire des transactions sans passer la session via toute la pile de fonctions. Dans l'app sur laquelle je bosse en ce moment, j'ai une ContextVar CURRENT_USER que je renseigne dans le décorateur qui authentifie chaque route de l'app et que je lis dans la couche qui gère les permissions. Le coeur du code, qui contient la couche permissions, expose donc un context manager qui permet de renseigner l'utilisateur, et c'est ce context manager que j'utilise dans l'app.
Au passage, pour les permissions, j'ai utilisé Oso que j'ai découvert via le blog de StackOverflow et j'ai trouvé ça franchement pratique. Bien mieux que le code spaghetti maison que j'avais fait avant. Pour la peine, je viens de poster un lien ici.
Il y a un pain avec le formattage de code de ton article, après "Pour les curieux, voici la partie du code transmettant le contexte aux threads".
# Alternative : vendre pour pièces
Posté par jihele . En réponse au journal J'essaie de commander des pièces détachées pour du petit électroménager. Évalué à 8.
Le moteur de mon ancien mixeur Seb a cassé.
J'ai acheté 30€ un mixeur Magimix (basique) d'occasion et j'ai revenu les pièces de mon mixeur cassé (les bols, les lames,…). Grâce à ça je pense avoir "sauvé" 4 ou 5 mixeurs et en plus j'ai récupéré à peu près 30€. C'est un peu pénible à faire mais je ne regrette pas l'opération.
# Configs utilisateur des logiciels
Posté par jihele . En réponse au message Migration Fedora → Debian. Évalué à 2.
C'est possible que les fichiers de config utilisateur des différents logiciels soient mal reconnus.
Si le logiciel est distribué différemment et le fichier n'est pas au même endroit ou pas au même format. Peu probable.
Si la version de logiciel est différente sur Debian, en particulier si elle est plus ancienne (si elle est plus récente, la transition doit se faire toute seule). Avec une Debian récente, c'est assez peu probable aussi.
Au pire, ça doit être marginal, mais le problème existe en théorie.
[^] # Re: update2
Posté par jihele . En réponse au journal compteur/montre gps sans synchro online. Évalué à 2.
Est-ce que tu fais la synchro des fichiers EPO manuellement ?
J'ai quelques pistes pour le faire. En vrac :
mais j'ai essayé rapidement sans succès sur la Garmin Instinct.
https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/instinct-solar/274887/manual-epo-update/1317524#1317524
[^] # Re: bof sauf peut-être pour les flux de syndication
Posté par jihele . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 2.
claws-mail a un plugin pour suivre les flux RSS mais ça reste en local. Il ne les copie pas en imap sur mon serveur de mail.
roundcube pourrait faire pareil de son côté. Avec l'inconvénient que le statut lu / non lu ne serait pas synchronisé entre les deux clients, bien sûr.
[^] # Re: bof sauf peut-être pour les flux de syndication
Posté par jihele . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 2.
J'aimerais bien un plugin RSS pour Roundcube mais j'ai jamais trouvé.
J'ai ça dans mon client lourd (claws-mail) mais pas dans mon webmail.
[^] # Re: petite remarque sur la dépêche
Posté par jihele . En réponse à la dépêche Sortie de MATE 1.26. Évalué à 4.
Tant qu'on y est, je pinaille :
s/extraction des archives RAR cryptées/extraction des archives RAR chiffrées/
[^] # Re: update2
Posté par jihele . En réponse au journal compteur/montre gps sans synchro online. Évalué à 6.
J'ai une Garmin Instinct Solar.
Je peux récupérer les .fit en mass storage. Un autre commentaire ici indique un outil pour en faire du GPX.
Je peux charger des GPX en mass storage. Il faut les mettre dans le dossier "NEWFILES" et ensuite la montre se débrouille. J'ai trouvé l'info au détour d'un forum, c'était pas dans la doc. Content de pouvoir écrire ça ici pour la postérité francophone.
J'ai vue une revue de la montre qui disait que l'appli était super nécessaire à l'utilisation. Franchement, je trouve pas. C'est nécessaire pour la customisation des objectifs quotidiens (que j'utilise pas) mais pour le reste (définition des entraînements, customisation des écrans) j'ai jamais été bloqué.
[^] # Re: Une montre ça ne sert à rien !
Posté par jihele . En réponse au journal compteur/montre gps sans synchro online. Évalué à 5.
Il s'est perdu et par chance, il a trouvé des pains au chocolat.
[^] # Re: Le volé puni?
Posté par jihele . En réponse au journal Pass Covid, une liste noire ?. Évalué à 7.
Sa phrase est pourtant assez claire. Il menace les gens qui prêtent leur pass. Mais c'est peut-être encore une phrase balancée comme ça sans réfléchir à la faisabilité.
Les restaurateurs et commerçants sont déjà un peu réticents à faire les flics à l'entrée de leurs établissements. C'est une chose de se résigner à contrôler, c'en est une autre de leur demander en plus de dénoncer les fraudeurs.
# Conclusion provisoire
Posté par jihele . En réponse au lien April : Atelier-directive-dsp2, wiki sur l’authentification forte pour les paiements par Internet. Évalué à 2.
(Initialement posté ici par erreur)
Reste que ça repose sur un SMS donc une ligne mobile, pour une consultation de comptes ou un achat qui ne nécessite qu'internet. (Avec alternative potentielle à base de dispositif physique unique type lecteur de carte CB générateur de code.)
La solution mise en place par PayPal décrite dans mon commentaire ici me paraitrait utile comme troisième possibilité.
A noter qu'une appli OTP ça peut tourner sur un ordi, une tablette, un vieux smartphone récupéré qu'on n'utilise qu'en WIFI, donc ça n'impose pas un smartphone + un abonnement.
[^] # Re: OTP
Posté par jihele . En réponse au lien Les changements introduits par la DSP2 (alternatives aux applis). Évalué à 3.
C'est pas complètement contradictoire.
Pour bosser un fichier de traitement de texte, il y a une logique à le faire en local plutôt que le charger dans le cloud et bosser dans un navigateur : confidentialité, performance de l'IHM. Même s'il y a des fonctionnalités pertinentes dans le cloud : rédaction à plusieurs. L'information est naturellement présente côté client.
A l'inverse, pour lire des infos sur un site web, l'info est naturellement présente côté serveur, et le web est un standard qui permet à chacun d'y avoir accès sans préjuger de quoi que ce soit (ou presque), et c'est mieux d'un point de vue interopérabilité, confidentialité, etc. En contrepartie, il peut y avoir un léger gain en IHM à passer par une appli dédiée, surtout sur un smartphone.
Enfin on est sur DLFP, quand-même, donc ne pas perdre de vue client libre vs. appli proprio.
Weboob, par ailleurs, ça sert à sortir du browser, mais pas pour enferme l'utilisateur, justement pour lui permettre d'automatiser ou de faire à sa sauce des choses qu'il peut faire parce qu'il s'appuie sur le web (faute d'avoir une vraie API vraiment ouverte).
Je ne vois pas de contradiction.
# Conclusion provisoire
Posté par jihele . En réponse au lien Les changements introduits par la DSP2 (alternatives aux applis). Évalué à 3.
Reste que ça repose sur un SMS donc une ligne mobile, pour une consultation de comptes ou un achat qui ne nécessite qu'internet. (Avec alternative potentielle à base de dispositif physique unique type lecteur de carte CB générateur de code.)
La solution mise en place par PayPal décrite dans mon commentaire ici me paraitrait utile comme troisième possibilité.
A noter qu'une appli OTP ça peut tourner sur un ordi, une tablette, un vieux smartphone récupéré qu'on n'utilise qu'en WIFI, donc ça n'impose pas un smartphone + un abonnement.
# OTP
Posté par jihele . En réponse au lien Les changements introduits par la DSP2 (alternatives aux applis). Évalué à 3.
Pour me connecter à PayPal, j'utilise
Le principe c'est qu'une fois connecté à mon compte PayPal j'ai demandé la génération d'un code (8 chiffres) affiché uniquement lors de sa génération, une sorte de token, que je renseigne dans mon générateur d'OTP (un logiciel libre mais on peut aussi utiliser Google Authenticator si on y tient ou si ça fait plus sexy).
Ça doit être plus ou moins équivalent au boîtier dans lequel on insère la CB pour générer des codes sauf que c'est pas la détention de la CB et la connaissance de son code qui font foi mais la connaissance du code initial à 8 chiffres qui a servi à initialiser l'appli OTP.
Pas besoin de smartphone ni de téléphone tout court ni de boîtier. Il faut juste avoir un dispositif avec un générateur d'OTP initialisé avec le code. Ça peut être un smartphone, auquel cas c'est déjà mieux puisqu'on a pas besoin de l'appli de la banque (mais peut-être que la banque préfère "imposer" son appli ?). Ça peut être l'ordi de la maison et celui du boulot. Bref, c'est un poil plus souple que le boîtier. Ça peut même être installé sur un serveur perso pour être accessible de n'importe-où même si c'est un peu plus sioux.
J'imaginais que c'était conforme DSP2 et que les banques pourraient faire pareil.
Pas sûr qu'on en prenne le chemin. A La Poste ils veulent à tout prix imposer l'appli (donc le smartphone) à tout le monde pour accéder à ses comptes.
Je crains le jour où le web ne servira plus qu'à aller lire DLFP, pour le reste il faudra des applis de smartphone privatrices.
[^] # Re: Chromium
Posté par jihele . En réponse au journal Du nommage des applications, des descriptions. Que dire, que faire ?. Évalué à 2.
Merci, c'est plus clair.
Je prendrais probablement pas le temps de creuser. Je n'utilise Chromium qu'épisodiquement, si j'ai une difficulté avec Firefox, ou pour tester le rendu d'un dev.
Si je comprends bien, Debian fait déjà un peu le boulot, c'est déjà ça.
# Chromium
Posté par jihele . En réponse au journal Du nommage des applications, des descriptions. Que dire, que faire ?. Évalué à 5.
Je croyais que chromium c'était justement la base de Google Chrome (et maintenant Edge ?), c'est-à-dire Google Chrome sans les googleries.
Il y a quoi de plus (de moins) dans ungoogled-chromium ?
[^] # Re: Extension Firefox : SingleFile
Posté par jihele . En réponse au message équivalent Httrack[résolu]. Évalué à 2.
OK, merci. Je voulais dire Ctrl+s, bien sûr.