Fonctionnalité #13878
ouvert
Utilisateurs : Réinitialisation des mots de passe suite à injection SQL
Ajouté par Robin SALDINGER il y a plus de 4 ans.
Mis à jour il y a plus d'un an.
Statut:
Complément d'Informations
Version cible:
Backlogs Produits - Inscription Backlog
Description
Contexte
Je débute un projet avec un client. Je lui fournis le tableau de paramétrage qu'il me renvoi rempli avec ses données (surtout ses users). J'intègre le sql généré par ce tableau dans Maarch Courrier.
En 1904 :
-
a la première connexion, les users créés via tableau se connectaient avec le mdp maarch et étaient invités à changer leur mdp.
--> OK
-
le superadmin pouvait réinitialiser le mdp des users, qui étaient invités à le modifier à la prochaine reconnexion.
--> OK
-
Par la suite, a la première connexion, les users créés graphiquement se connectaient avec le mdp maarch et étaient invités à changer leur mdp.
--> OK
-
Concrètement, à l'injection/création des users et lorsque superadmin réinitialisait manuellement le mdp, le champ "change_password" de la table "users" passait de "f" à "t". Par la suite, on pouvait réinitialiser l'ensemble de mdp de la base via une simple requête sql.
--> OK
Maintenant en 2003, la logique a changée : on ne parle plus de réinitialisation mais d'un envoi de mail, qui invite à modifier le mot de passe. donc :
-
à la première connexion, les users créés via tableau se connectent avec le mdp maarch : ils ne sont plus invités à modifier leur mdp. Il faut qu'ils se rendent dans "profil" > "modifier mon mdp"
--> PAS OK : ces users ne sont pas forcés de créer un nouveau mdp, certains ne le feront pas par facilité (c'est sur)
-
le superadmin ne peut que "renvoyer le courriel d'activation", ce qui ne force pas la réinitialisation des mdp des users qui n'auraient pas changés manuellement le leur.
--> PAS OK : avant le superadmin s'assurait qu'en cliquant sur "reinitialiser le mdp", le mdp serait obligatoirement changé par le user. Il faut également qu'il s'assure que l'adresse mail de l'user est bonne.
-
Par la suite, à la première connexion, les users créés graphiquement ne peuvent pas se connecter tant qu'ils n'ont pas définis leur mdp grâce au mail.
**--> OK :**le mdp par défaut est généré aléatoirement, l'user est obligé d'en changer pour pouvoir se connecter
-
De plus, le champ "change_password" de la table "users" a disparu.
--> PAS OK : On ne peut plus réinitialiser l'ensemble de mdp de la base via une requête sql.
Du coup la question est : comment forcer les utilisateurs à modifier leur mot de passe à la première connexion quand ils ont été intégrés grâce à un tableau de paramétrage (80% des users) ?
Ici on ne peut pas mettre un mot de passe complexe par défaut (sans leur donner) et les inviter à cliquer sur "mdp oublié" à la première connexion car dans le cadre de projets avec des users génériques par exemple, l'adresse mail associée l'est aussi (générique).
Fichiers
- Tracker changé de Régression à Fonctionnalité
- Statut changé de A qualifier à R&D - A étudier
Lié à l'injection SQL du Param
- Statut changé de R&D - A étudier à Etude planifiée
- Description mis à jour (diff)
- Sujet changé de Réinitialiser les mots de passe des utilisateurs à la première connexion suite à une injection de PARAM à Utilisateurs : Réinitialisation des mots de passe suite à injection SQL
- Injection SQL : mot de passe par défaut (générer et communiquer les mdp...)
- Renvoi du courriel d'activation : si suivi lien, chgt mdp, sinon, le mot de passe initial est toujours actif.
-> obliger un utilisateur à changer son mdp (forcer la réinitialisation du mot de passe) flag.
- Statut changé de Etude planifiée à 17
- Assigné à changé de EDI PO à Robin SALDINGER
- Statut changé de 17 à A traiter
- Assigné à changé de Robin SALDINGER à EDI PO
Emmanuel DILLARD a écrit :
- Injection SQL : mot de passe par défaut (générer et communiquer les mdp...)
- Renvoi du courriel d'activation : si suivi lien, chgt mdp, sinon, le mot de passe initial est toujours actif.
-> obliger un utilisateur à changer son mdp (forcer la réinitialisation du mot de passe) flag.
- C'est une injection des nouveaux comptes utilisateurs en masse via des requetes sql généré à partir du fichier de paramétrage 2003.
- le fichier de param ne permet pas de générer aléatoirement un mot de passe
- le souhait est de :
- permettre d'envoyer un mail de réinitialisation du mot de passe en masse à tous les utilisateurs en un clic.
ou
- permettre de générer un mail indiquant qu'un compte a été créé pour cette utilisateur.
Emmanuel DILLARD a écrit :
-> utiliser la création via WS et plus par SQL
(contrôles et mécanisme absents en SQL)
https://docs.maarch.org/gitbook/html/MaarchCourrier/20.03/guat/guat_architecture/API_REST/Users.html
Contournement :
Activer l'expiration des mots de passe (ex 1 jour)
Mettre une date antérieure dans password_modification_date des users (< 1 jour)
Pensez à désactiver.
- lors de la création en WS, le mail est bien généré, sauf que le fichier de param ne permet pas d'injecter en ws. ==> est ce que c'est dans la roadmap des développeur, d'ajouter une fonctionnalité permettant d'injecter en ws?
- Est ce que l'expiration du mot de passe envoi automatiquement un mail à l'utilisateur?
- L'idée est que ça soit automatique.
Pour info c'est une demande de JLE
Je viens de faire le test de création d'un compte pour voir si il y a un envoi de mail lors de l'expiration comme demandé ci-dessus:
- modification dans l'administration de la sécurité et passage de l'expiration du mot de passe à 1 jour
- injection du compte en sql à 11:00 - 14-05-2020
- en base de données, modification du champs password_modification_date de la table user du compte nouvellement créé avec la valeur 11:05 - 14-05-2020
- attente du mot de passe à 11:05 - 14-05-2020
- aucune réception de mail d'expiration à 11:05 - 14-05-2020 ni à 11:06 - 14-05-2020
==> en faisant ce test, ceci montre que malgré l'ajout d'une date d'expiration, il n'y a pas de mail demandant à la personne de modifier son mot de passe.
- Statut changé de A traiter à 17
- Assigné à changé de EDI PO à Henri QUENEAU
Lorsque le mot de passe expire, il n'y a pas de tache d'envoi de notification utilisateur, mais une invite à la connexion.
A tester : invite de connexion de l'utilisateur dont le mot de passe est expiré
(identifiant utilisateur et mdp par défaut injecté via SQL)
-> il n'y a pas de ticket roadmap sur un outil d'injection par WS (user ou autre)
-> l'expiration du mot de passe ne notifie pas l'utilisateur. C'est à l'invite de connexion que le processus s'opère.
Pour que ce soit standard (et automatique), il est nécessaire de passer par injection WS
- Assigné à changé de Henri QUENEAU à Robin SALDINGER
Nous proposons une réunion pour systématiser l'utilisation et l'injection par WS.
Pour ne pas pérenniser l'injection SQL au bénéfice/ risque peu avantageux
- Assigné à changé de Robin SALDINGER à Henri QUENEAU
- Priorité changé de 1-Majeur à 2-Sérieux
- Statut changé de 17 à Complément d'Informations
- Projet changé de 298 à Backlog Courrier
- Version cible changé de Inscription Backlog Courrier à Inscription Backlog
- Assigné à changé de Henri QUENEAU à Sarah BAZIN
- Priorité changé de 2-Sérieux à 3-Mineur
- Assigné à changé de Sarah BAZIN à Nathanaël TRAVIER
Formats disponibles : Atom
PDF