Produits Entr'ouvert » Authentic 2

Oui c'est une bonne approche, à toi de voir comment tu récupères le hash depuis les appels au WS (nouveau champ, nouveau type de valeur pour le champ existant "password").

A priori ce serait un nouveau champ.

Par contre Thomas n'est pas très chaud parce qu'il n'y a pas d'API Django de prévue à cet effet et plus particulièrement à cause du Save qui utilise un attribut privé.
django/contrib/auth/base_user.py::AbstractBaseUser :

    # Stores the raw password if set_password() is called so that it can
    # be passed to password_changed() after the model is saved.
    _password = None
...
    def save(self, *args, **kwargs):
        super().save(*args, **kwargs)
        if self._password is not None:
            password_validation.password_changed(self._password, self)
            self._password = None

Perso je dirais que l'attribut _password est remis à None après utilisation et donc que "ça passe".
Tu en penses quoi ?

Nicolas Roche a écrit :

A priori ce serait un nouveau champ.

Par contre Thomas n'est pas très chaud parce qu'il n'y a pas d'API Django de prévue à cet effet et plus particulièrement à cause du Save qui utilise un attribut privé.
django/contrib/auth/base_user.py::AbstractBaseUser :
[...]

Perso je dirais que l'attribut _password est remis à None après utilisation et donc que "ça passe".
Tu en penses quoi ?

Je ne connaissais pas, ça doit être récent (django 1.11) je dirai qu'on s'en fout, c'est juste pour valider le format du mot de passe, et c'est l'implémentation Django de ce truc, on en a une autre dans a2 qu'on applique pas non plus sur les WS il me semble.

Bon après pour reprendre le cas d'usage évoqué de base je ne vois pas ce que ça nous apporte, ok le mot de passe n'est pas envoyé en clair à a2 mais il est de toute façon conservé en clair dans la demande coté w.c.s. vu l'implémentation de PasswordField. Je rate un truc ?

Ok j'ai lu que le code de PasswordEntryWidget, pas vu que PasswordField limiter les formats, ça a un sens alors. Pour le format du hash de toute façon Django mets à jour vers le format souhaité à chaque login si nécessaire, ce n'est donc pas bien grave.

Nicolas Roche a écrit :

Vu #35533, la construction des hash se fera en amont dans wcs.
Je n'ai pas trouvé comment valider (proprement) le format du hash passé.

Tu as une fonction identify_hasher dans django.contrib.auth.hashers pour faire ça, ce n'est pas une API très publique mais elle est là.

La doc django (https://docs.djangoproject.com/fr/1.11/topics/auth/passwords/ ) indique :
[...]
ce qui exclus par exemple les anciens formats sans itérations gérés par A2 :
[...]

Est-ce que d'après vous je peux me baser sur ces 2 formats ou est-ce
que j'accepte sans regarder ?

Tu peux tenter un hasher.safe_summary(encoded) et refuser ce qui est envoyé si ça retourne la moindre exception, mais clairement sans le mot de passe en clair et une petite connaissance de l'algo en question t'as aucun moyen de savoir si ce qu'on t'envoie à un sens ou si ça peut être dangereux; genre on peut t'envoyer un nombre d'itération monstrueux ce qui est en fait un DOS (la prochaine fois que cette personne va se connecter ça va bloquer un worker jusqu'à ce que ça timeout, parce que ça va faire tenter de faire des milliards de calculs de hash).