Pouvoir afficher les caractères saisis dans le champ de mot de passe du formulaire de connexion #4872

Open
opened 3 weeks ago by MathieuAlphamosa · 12 comments

Je vous propose cette petite amélioration, tirée de la checklist Opquast, pour le formulaire de connexion à l'espace privé :

Règle n° 74 - Les caractères saisis dans un champ de mot de passe peuvent être affichés en clair.
https://checklists.opquast.com/fr/assurance-qualite-web/les-caracteres-saisis-dans-un-champ-de-mot-de-passe-peuvent-etre-affiches-en-clair

Si j'ai le feu vert j'essaye de m'y coller prochainement.

Je vous propose cette petite amélioration, tirée de la checklist Opquast, pour le formulaire de connexion à l'espace privé : **Règle n° 74 - Les caractères saisis dans un champ de mot de passe peuvent être affichés en clair.** https://checklists.opquast.com/fr/assurance-qualite-web/les-caracteres-saisis-dans-un-champ-de-mot-de-passe-peuvent-etre-affiches-en-clair Si j'ai le feu vert j'essaye de m'y coller prochainement.

Peut-être génériquement un script JS existant qu'on n'aurait pas à maintenir, et qui ajoute un picto-bouton sur le champ (ou juste après) pour démasquer le texte ? Et qui pourrait donc être chargé, dans l'admin ou n'importe quel page (puisque notamment le form de connexion peut être n'importe où).

Peut-être génériquement un script JS existant qu'on n'aurait pas à maintenir, et qui ajoute un picto-bouton sur le champ (ou juste après) pour démasquer le texte ? Et qui pourrait donc être chargé, dans l'admin ou n'importe quel page (puisque notamment le form de connexion peut être n'importe où).

Bon, c'était évidement plus compliqué que je ne l'avais prévu.
Voilà un premier jet : https://git.spip.net/MathieuAlphamosa/spip/src/branch/issue_4872
Constitué de 3 modifications :

preview du toggle de mot de passe

Pour information, je me surtout inspiré de cet article qui a le mérite d'expliquer les différents problèmes pouvant être rencontrés : https://components.publishing.service.gov.uk/component-guide/show_password

Si ça vous semble OK il me reste les modifications suivantes à travailler :

  • passer le code JS dans prive/javascript/login.js
  • en faire une version minifiées pour l'ajouter à prive/javascript/login-sha-min.js
  • travailler les CSS pour la version publique du formulaire
  • deux nouvelles chaînes de traductions à prévoir "Afficher le mot de passe", "Masquer le mot de passe"

J'espère que je m'y prends correctement, j'ai pas l'hébitude de git...

Bon, c'était évidement plus compliqué que je ne l'avais prévu. Voilà un premier jet : https://git.spip.net/MathieuAlphamosa/spip/src/branch/issue_4872 Constitué de 3 modifications : - https://git.spip.net/MathieuAlphamosa/spip/commit/631d0b4163c6bd76fcb04eae2dbd4272a4399579 - https://git.spip.net/MathieuAlphamosa/spip/commit/8d89eb573773682e1d81bd23cb49fdb7b2d6202e - https://git.spip.net/MathieuAlphamosa/spip/commit/224e573e1eaddf2ce32b805f0efec40487b46d9c ![preview du toggle de mot de passe](https://i.imgur.com/sGHD75p.gif) Pour information, je me surtout inspiré de cet article qui a le mérite d'expliquer les différents problèmes pouvant être rencontrés : https://components.publishing.service.gov.uk/component-guide/show_password Si ça vous semble OK il me reste les modifications suivantes à travailler : - passer le code JS dans prive/javascript/login.js - en faire une version minifiées pour l'ajouter à prive/javascript/login-sha-min.js - travailler les CSS pour la version publique du formulaire - deux nouvelles chaînes de traductions à prévoir "Afficher le mot de passe", "Masquer le mot de passe" J'espère que je m'y prends correctement, j'ai pas l'hébitude de git...
b_b commented 2 weeks ago
Owner

Top, merci beaucoup pour le rapport détaille, la source d'inspiration, le gif, tout ça quoi, c'est prop'

Perso ça me semble très bien, je laisse @tcharlss & @marcimat donner leur avis sur la partie CSS vu qu'ils ont beaucoup travaillé là dessus dernièrement.

Concernant le js, à part des pétouilles de PSR ça me semble bien, juste une question : pourquoi faut-il l'ajouter à login.js et javascript/login-sha-min.js ?

Top, merci beaucoup pour le rapport détaille, la source d'inspiration, le gif, tout ça quoi, c'est prop' Perso ça me semble très bien, je laisse @tcharlss & @marcimat donner leur avis sur la partie CSS vu qu'ils ont beaucoup travaillé là dessus dernièrement. Concernant le js, à part des pétouilles de PSR ça me semble bien, juste une question : pourquoi faut-il l'ajouter à login.js et javascript/login-sha-min.js ?

Si j'ai bien compris login-sha-min.js est une version concaténée et minifiée des fichiers sha256.js et login.js. Et j'ai l'impression que c'est fait manuellement, quand c'est nécessaire.
C'est ce fichier login-sha-min.js qui est inclu dans le formulaire de login.

Si j'ai bien compris login-sha-min.js est une version concaténée et minifiée des fichiers sha256.js et login.js. Et j'ai l'impression que c'est fait manuellement, quand c'est nécessaire. C'est ce fichier login-sha-min.js qui est inclu dans le formulaire de login.

Super pour le résultat !

J'ai quelques remarques sur le JS 👍:

  • Les boutons ne sont utilisables que s'il y a JS : à priori ils devraient donc n'être présents que s'il y a JS, il ne faut pas les générer dans le HTML directement. Et donc que c'est au JS de les insérer au besoin.
  • Vu qu'on ajoute là un tout nouveau truc, est-ce qu'on ne devrait pas directement le rendre un peu générique ? C'est-à-dire que ça génère ce bouton (et son comportement) pour tout champ password qui le demande, dans le genre : $('input[type=password].password_basculer').activer_password_basculer(); et dans login.html il faudrait donc juste ajouter cette classe pour "demander" cette fonctionnalité. Mais ça permet à d'autres endroits de le demander aussi.

Cela dit (mais tu as déjà dû chercher), n'existe-il pas déjà une lib JS qui ajouterait ça en générique, accessible, sans qu'on ait besoin de maintenir la fonctionnalité chez nous, juste l'appeler ?

Super pour le résultat ! J'ai quelques remarques sur le JS 👍: - Les boutons ne sont utilisables que s'il y a JS : à priori ils devraient donc n'être présents que s'il y a JS, il ne faut pas les générer dans le HTML directement. Et donc que c'est au JS de les insérer au besoin. - Vu qu'on ajoute là un tout nouveau truc, est-ce qu'on ne devrait pas directement le rendre un peu générique ? C'est-à-dire que ça génère ce bouton (et son comportement) pour tout champ password qui le demande, dans le genre : `$('input[type=password].password_basculer').activer_password_basculer();` et dans login.html il faudrait donc juste ajouter cette classe pour "demander" cette fonctionnalité. Mais ça permet à d'autres endroits de le demander aussi. Cela dit (mais tu as déjà dû chercher), n'existe-il pas déjà une lib JS qui ajouterait ça en générique, accessible, sans qu'on ait besoin de maintenir la fonctionnalité chez nous, juste l'appeler ?
  • Les boutons ne sont utilisables que s'il y a JS : à priori ils devraient donc n'être présents que s'il y a JS, il ne faut pas les générer dans le HTML directement. Et donc que c'est au JS de les insérer au besoin.

J'avais commencé comme ça et je suis passé en HTML par fainéantise, je vais refaire ça.

  • Vu qu'on ajoute là un tout nouveau truc, est-ce qu'on ne devrait pas directement le rendre un peu générique ? C'est-à-dire que ça génère ce bouton (et son comportement) pour tout champ password qui le demande, dans le genre : $('input[type=password].password_basculer').activer_password_basculer(); et dans login.html il faudrait donc juste ajouter cette classe pour "demander" cette fonctionnalité. Mais ça permet à d'autres endroits de le demander aussi.

Je suis un peu embêté avec cette façon de faire :

  • Ca veut dire ajouter un bout de JS qu'on se traîne partout (sites publiques et BO), même si il est jamais utilisé. Là il est au chaud dans un JS qui n'est appelé que dans le cas où on en a vraiment besoin : le formulaire de login.
  • Le bouton ajouté nécessite un peu de place et de CSS pour être affiché correctement, j'ai peur que ce ne soit pas franchement utilisable tel quel autre part.

Mais je me trompe peut être ? :) Je vais continuer à y réflechir.

Cela dit (mais tu as déjà dû chercher), n'existe-il pas déjà une lib JS qui ajouterait ça en générique, accessible, sans qu'on ait besoin de maintenir la fonctionnalité chez nous, juste l'appeler ?

J'ai rien trouvé d'acceptable ni de maintenu. Encore moins avec des problématiques d'accessibilité et de multilinguisme tel qu'on peut se les poser ici.

> - Les boutons ne sont utilisables que s'il y a JS : à priori ils devraient donc n'être présents que s'il y a JS, il ne faut pas les générer dans le HTML directement. Et donc que c'est au JS de les insérer au besoin. J'avais commencé comme ça et je suis passé en HTML par fainéantise, je vais refaire ça. > - Vu qu'on ajoute là un tout nouveau truc, est-ce qu'on ne devrait pas directement le rendre un peu générique ? C'est-à-dire que ça génère ce bouton (et son comportement) pour tout champ password qui le demande, dans le genre : `$('input[type=password].password_basculer').activer_password_basculer();` et dans login.html il faudrait donc juste ajouter cette classe pour "demander" cette fonctionnalité. Mais ça permet à d'autres endroits de le demander aussi. Je suis un peu embêté avec cette façon de faire : - Ca veut dire ajouter un bout de JS qu'on se traîne partout (sites publiques et BO), même si il est jamais utilisé. Là il est au chaud dans un JS qui n'est appelé que dans le cas où on en a vraiment besoin : le formulaire de login. - Le bouton ajouté nécessite un peu de place et de CSS pour être affiché correctement, j'ai peur que ce ne soit pas franchement utilisable tel quel autre part. Mais je me trompe peut être ? :) Je vais continuer à y réflechir. > Cela dit (mais tu as déjà dû chercher), n'existe-il pas déjà une lib JS qui ajouterait ça en générique, accessible, sans qu'on ait besoin de maintenir la fonctionnalité chez nous, juste l'appeler ? J'ai rien trouvé d'acceptable ni de maintenu. Encore moins avec des problématiques d'accessibilité et de multilinguisme tel qu'on peut se les poser ici.

Peut-être ai-je zappé des choses importantes mais dans le tout premier résultat google :
https://github.com/cloudfour/hideShowPassword

Ils indiquent :

Peut-être ai-je zappé des choses importantes mais dans le tout premier résultat google : https://github.com/cloudfour/hideShowPassword Ils indiquent : - [être accessible](https://cloudfour.com/thinks/hideshowpassword-2/#improved-accessibility), avec button + attributs aria - [la liste des options est énorme](https://github.com/cloudfour/hideShowPassword#options) ("Just about anything we could make an option, we have" disent-ils), et on peut parfaitement personnaliser toutes les chaines de langue lors de l'appel

Tu as raison, je l'avais sauté car je le voyais plus maintenu et je pensais, à tord, que le bouton ajouté l'était par dessus l'input password... ce qui pose des problèmes avec les gestionnaires de mots de passe, mais en fait non.

Je vais tester ça, merci.

Tu as raison, je l'avais sauté car je le voyais plus maintenu et je pensais, à tord, que le bouton ajouté l'était par dessus l'input password... ce qui pose des problèmes avec les gestionnaires de mots de passe, mais en fait non. Je vais tester ça, merci.
Owner

C'est top en effet.

Ce qui me pose problème (et j'ai pas trop la réponse), c'est que ce formulaire de login est usuellement utilisé par plein de squelettes qui proposent leur propre page de login et qu'on introduit du markup qui n'est pas dans les conventions de formulaire de SPIP.

Ce qui va se passer donc, c'est que le bouton 'afficher/masquer' va tomber partout où il est pas stylé et ça va être bien moche.

Du coup je vois 2 possibilités

  • prévoir un markup générique dans notre convention de formulaires pour pouvoir faire un input suivi (ou précédé) d'un bouton, comme le proposent pas mal de frameworks
  • masquer le bouton par défaut (avecun display:none dans le html), et charge à la css de l'afficher pour activer la fonction : ça permet de l'avoir si on a stylé le formulaire en conséquence et de ne pas casser les formulaires utilisés dans la nature... (mais ça va un peu à l'encontre de la remarque de @rastapopoulos qui voudrait injecter le html via le js)
C'est top en effet. Ce qui me pose problème (et j'ai pas trop la réponse), c'est que ce formulaire de login est usuellement utilisé par plein de squelettes qui proposent leur propre page de login et qu'on introduit du markup qui n'est pas dans les conventions de formulaire de SPIP. Ce qui va se passer donc, c'est que le bouton 'afficher/masquer' va tomber partout où il est pas stylé et ça va être bien moche. Du coup je vois 2 possibilités - prévoir un markup générique dans notre convention de formulaires pour pouvoir faire un input suivi (ou précédé) d'un bouton, comme le proposent pas mal de frameworks - masquer le bouton par défaut (avecun `display:none` dans le html), et charge à la css de l'afficher pour activer la fonction : ça permet de l'avoir si on a stylé le formulaire en conséquence et de ne pas casser les formulaires utilisés dans la nature... (mais ça va un peu à l'encontre de la remarque de @rastapopoulos qui voudrait injecter le html via le js)

@MathieuAlphamosa On peut voir les démos là : http://cloudfour.github.io/hideShowPassword/ et on voit effectivement que ça ne gêne pas du tout le gestionnaire/autocomplétion du navigateur.

Et on voit surtout que grace aux options, il y a plein de manières possibles :

  • un picto en interne
  • un chaine de langue en interne
  • une case à cocher qui suit le champ

Suivant le commentaire de @cerdic je pencherais justement pour la version picto en interne ce qui est immédiatement visible tel quel sans styles 99% du temps, généré en JS, et donc qui a très peu de risque de casser les pages existantes.

@MathieuAlphamosa On peut voir les démos là : http://cloudfour.github.io/hideShowPassword/ et on voit effectivement que ça ne gêne pas du tout le gestionnaire/autocomplétion du navigateur. Et on voit surtout que grace aux options, il y a plein de manières possibles : - un picto en interne - un chaine de langue en interne - une case à cocher qui suit le champ Suivant le commentaire de @cerdic je pencherais justement pour la version picto *en interne* ce qui est immédiatement visible tel quel sans styles 99% du temps, généré en JS, et donc qui a très peu de risque de casser les pages existantes.

Je suis en train de travailler sur l'intégration de la librairie hideShowPassword suggérée par @rastapopoulos, j'ai besoin d'être aiguillé sur un point précis.

  1. Soit je mets en place quelque chose de très générique comme sugéré par @rastapopoulos ici #4872 ce cas là on est obligé d'inclure la librairie partout via f_jQuery

  2. Soit je le mets en place uniquement sur le login de /ecrire/. Dans ce cas :

    • la librairie JS sera inclue dans le head de prive/login.html
    • le code JS sera mis en inline après le bout de code inline déjà présent (ligne 20)
    • le code CSS sera dans login_prive.css, au chaud avec le reste

J'avoue ne pas être super à l'aise avec la 1ère solution car on va ajouter une librairie JS de 15ko (8ko minimisée) et un peu de CSS (il y'a un SVG à mettre en place) sur tous les sites SPIP.
Ca me semble disproportionné alors que cette fonctionnalité sera utilisée principalement sur la page de login de /ecrire/.

Je suis en train de travailler sur l'intégration de la librairie hideShowPassword suggérée par @rastapopoulos, j'ai besoin d'être aiguillé sur un point précis. 1. Soit je mets en place quelque chose de très générique comme sugéré par @rastapopoulos ici https://git.spip.net/spip/spip/issues/4872#issuecomment-27934. Dans ce cas là on est obligé d'inclure la librairie partout via f_jQuery 2. Soit je le mets en place uniquement sur le login de /ecrire/. Dans ce cas : - la librairie JS sera inclue dans le head de prive/login.html - le code JS sera mis en inline après le bout de code inline déjà présent (ligne 20) - le code CSS sera dans login_prive.css, au chaud avec le reste J'avoue ne pas être super à l'aise avec la 1ère solution car on va ajouter une librairie JS de 15ko (8ko minimisée) et un peu de CSS (il y'a un SVG à mettre en place) sur tous les sites SPIP. Ca me semble disproportionné alors que cette fonctionnalité sera utilisée principalement sur la page de login de /ecrire/.
Owner

Personnellement, je connais plein de sites (dont ceux officiels de la galaxie SPIP), où le form de login est aussi :

  • soit sur toutes les pages restreintes dans tous les sites qui ont Accès Restreint, càd sur la page 401 au moins ou plus (pour les sites qui affichent 200 les pages restreintes mais seulement avec une intro et le login)
  • soit sur 100% des pages, parce que le form est affiché dans un bloc permanent du site (entête ou ce genre), soit dans une box qui s'ouvre (et donc on a pas accès à un autre head) : c'est le cas sur Contrib par ex

Bé pour tous ces cas, la lib devrait aussi améliorer l'ergonomie du mot de passe, il me semble. Surtout que là je parle d'exemple où c'est même pas d'autres forms, mais le même form inséré dans plein d'autres pages possibles (donc avec n'importe quel head possible).

Après ya aussi des techniques pour charger le JS que à tel endroit : c'est ce que fait GIS par ex. Mais je ne suis pas le plus à l'aise pour décrire ça, on n'a jamais documenté quand utiliser telle ou telle méthode et comment le faire au plus propre quand on veut charger que à certains endroits.

Personnellement, je connais plein de sites (dont ceux officiels de la galaxie SPIP), où le form de login est aussi : - soit sur toutes les pages restreintes dans tous les sites qui ont Accès Restreint, càd sur la page 401 au moins ou plus (pour les sites qui affichent 200 les pages restreintes mais seulement avec une intro et le login) - soit sur 100% des pages, parce que le form est affiché dans un bloc permanent du site (entête ou ce genre), soit dans une box qui s'ouvre (et donc on a pas accès à un autre head) : c'est le cas sur Contrib par ex Bé pour tous ces cas, la lib devrait aussi améliorer l'ergonomie du mot de passe, il me semble. Surtout que là je parle d'exemple où c'est même pas d'autres forms, mais le même form inséré dans plein d'autres pages possibles (donc avec n'importe quel head possible). Après ya aussi des techniques pour charger le JS que à tel endroit : c'est ce que fait GIS par ex. Mais je ne suis pas le plus à l'aise pour décrire ça, on n'a jamais documenté quand utiliser telle ou telle méthode et comment le faire au plus propre quand on veut charger que à certains endroits.
b_b added the
amélioration
accessibilité
labels 18 hours ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.