Projet

Général

Profil

Bug #20731

crash LDAP sur changement de mot de passe

Ajouté par Thomas Noël il y a plus de 6 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
15 décembre 2017
Echéance:
% réalisé:

100%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Il semble qu'en cas de backend LDAP Authentic cherche à modifier le mot de passe sur ce dernier, mais qu'en cas de problème on ait un crash, cf #20729 et trace visible sur la copie d'écran attachée


Fichiers

Révisions associées

Révision 93b2cf18 (diff)
Ajouté par Benjamin Dauvergne il y a presque 6 ans

disable password change for LDAP backend without user_can_change_password (fixes #20731)

Révision 26d39e05 (diff)
Ajouté par Benjamin Dauvergne il y a presque 6 ans

tests: adapt test to new organization name (#20731)

Historique

#3

Mis à jour par Thomas Noël il y a plus de 6 ans

  • Fichier FireShot Capture 1 - INSUFFICIENT_ACCESS at _accounts_passw_ - https___connexion-preprod-moncompte.png supprimé
#5

Mis à jour par Frédéric Péters il y a presque 6 ans

Autre trace possible sur la même cause, non pas INSUFFICIENT_ACCESS mais UNWILLING_TO_PERFORM :

  File "/usr/lib/python2.7/dist-packages/authentic2/backends/ldap_backend.py", line 177, in set_password
    self.ldap_backend.modify_password(conn, self.block, self.dn, old_password, new_password)
  File "/usr/lib/python2.7/dist-packages/authentic2/backends/ldap_backend.py", line 975, in modify_password
    conn.modify_s(dn, modlist)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 357, in modify_s
    return self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 458, in result
    resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 462, in result2
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
UNWILLING_TO_PERFORM: {'info': '00002077: SvcErr: DSID-03190E49, problem 5003 (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to perform'}
#6

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

  • Statut changé de Nouveau à Solution proposée
  • Assigné à mis à Benjamin Dauvergne

Même réponse que #20729:

Il faut dire que les utilisateurs n'ont pas le droit de changer de mot de passe:

        # Can users change their password ?
        'user_can_change_password': True,

mettre False.

#7

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

Bon le unwilling to perform ça peut aussi venir de la politique de mot de passe coté AD1, peut-être faudrait-il le récupérer mais malheureusement on a pas moyen de faire remonter l'erreur jusqu'au formulaire :/

[1]: https://communities.ca.com/thread/241769648-password-reset-failed-code-53-unwillingtoperform

Donc une autre solution possible c'est de voir comment catcher toute erreur sur .set_password() et la rapporter plus ou moins proprement sur le formulaire.

#8

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

Benjamin Dauvergne a écrit :

Bon le unwilling to perform ça peut aussi venir de la politique de mot de passe coté AD1, peut-être faudrait-il le récupérer mais malheureusement on a pas moyen de faire remonter l'erreur jusqu'au formulaire :/

[1]: https://communities.ca.com/thread/241769648-password-reset-failed-code-53-unwillingtoperform

Donc une autre solution possible c'est de voir comment catcher toute erreur sur .set_password() et la rapporter plus ou moins proprement sur le formulaire.

En plus AD ne rapporte le détail de l'erreur (trop long, pas assez long, déjà utilisé, who knows...).

#9

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

  • Statut changé de Solution proposée à Nouveau

Bon en fait le souci ici c'est que ça ne marche plus, à un moment [1] on a changé le comportement de la vue de changement de mot de passe qui si l'utilisateur n'avait pas un mot de passe "utilisable" refusait d'en définir un. Maintenant c'est possible. Sauf que le backend LDAP utilisait justement la méthode .has_usable_password() pour passer la valeur de 'user_can_change_password', surcharge sémantique malheureuse. Maintenant qu'on peut définir (et non plus juste redéfinir) un mot de passe over LDAP ça ne marche plus.

Bon ce que ça veut dire c'est qu'il faut une méthode .can_change_password() dont le sens sera évident.

[1]:

commit 2ba49444042e560ef1cba943c1fb6f7af00946c0
Author: Mikaël Ates <mates@entrouvert.com>
Date:   Wed Apr 20 22:13:51 2016 +0200

    Adapt account management when the user has no password (fixes #10658).

#10

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

#11

Mis à jour par Frédéric Péters il y a presque 6 ans

  • Statut changé de Solution proposée à Solution validée

Sujet de commit un peu trop long mais je ne propose pas de reformulation.

#12

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

  • Statut changé de Solution validée à Résolu (à déployer)
  • % réalisé changé de 0 à 100
#13

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF