Produits Entr'ouvert » w.c.s.

• y'a un "user.hash()" qui traine alors que hash est une property
• j'ajouterai bien un hint sur la config du sel, qui dirait « Une fois la valeur du sel choisie, ne la modifiez plus.», quitte à expliquer également à quoi sert ce sel (il rend la liaison entre utilisateur et formulaire unilatérale... mais je ne sais pas trop comment l'expliquer sans faire un roman).

Pour moi le sel en question est une configuration inutile, je verrai bien ça comme un truc auto-généré si absent du config.pck au lancement de w.c.s, où à la création du répertoire pour un domaine. Et pour le nommage je propose plutôt que sel comme dans Django la variable de configuration SECRET_KEY. C'est un secret qui sert un peu à tout, signer les cookies, saler les hash des mots de passe, etc..

On pourrait se contenter d'une case à cocher, cochable une fois, qui derrière générerait ce bout d'aléatoire; par contre je tiens à ce que sa fonction soit et reste limitée à la création d'un hash d'un utilisateur.

Pourquoi le "Beware this setting cannot be reverted" ? Selon moi, si on désactive, ça va redonner une bijection formdata<->user, mais la liste des formulaires liés à un utilisateur fonctionnera toujours, y compris pour ceux stockés avec un hash... Non ?

redmine@entrouvert.com écrivait:

Pourquoi le "Beware this setting cannot be reverted" ? Selon moi, si
on désactive, ça va redonner une bijection formdata<->user, mais la
liste des formulaires liés à un utilisateur fonctionnera toujours,
y compris pour ceux stockés avec un hash... Non ?

Je pense qu'il faut signifier que pour les formulaires soumis durant
l'activation de l'option c'est irréversible; mais en même temps ça me
parait implicite avec l'existence d'une case à cocher et l'intitulé de
l'option. Pour des option one-shot comme la conversion vers utf8 c'est
mieux d'utiliser un bouton qui disparait une fois utilisé.

Je ne comprends pas en quoi c'est "irreversible"... On peut très bien la réactiver, et ça va recréer un lien fort user/form le temps de désactivation... et si on réactive, ça refait du hash...

En revanche, un truc important à faire selon moi : si l'option est activée, retirer les variables "form_user*" de la liste affichée (cf les Substitutions.register correspondant à la fin de formdata.py).

Ca permet notamment de "faire comprendre le principe".

Le "cannot be reverted", c'est parce que le hashage se fait si le sel est mis, donc repasser en mode non hashé signifie enlever la valeur de la clé secrète, et donc les formulaires enregistrés avec un user_hash ne pourront plus être liées.

Alors bien sûr il est possible d'avoir deux paramètres dans les préférences, le fait de hasher ou pas, et la clé secrète.

On fait, on fait pas ?

Frédéric Péters a écrit :

Correction d'un petit bug (user_id utilisé là où ça devrait être user).

mmmh... j'ai l'impression qu'au passage, il n'y a plus la séparation use_user_hash/user_hash_secret_key et qu'on a perdu le sha256... non ? (voir note 16 ci-dessus)