Bug #1276
user_hash désactivé => crash sur les formulaires avec user_hash
100%
Description
Problème de la réversibilité de l'option "Association à sens unique entre un utilisateur et ses formulaires" :
- Je passe un site en mode "use_user_hash"
- J'enregistre un formulaire
- L'accès au formulaire marche, sans problème
- Je reviens en mode normal (use_user_hash=False)
- Si je veux accéder à mon formulaire, j'ai la trace ci-dessous.
Il faudrait éventuellement distinguer le cas où on veut juste obtenir le user_hash quand la clé user_hash_secret_key existe, sans tester l'existence de use_user_hash ?
i.e. ne pas déclencher d'exception AttributeError lors de l'accès à user.hash si la clé existe.
i.e. dans le reste du code ne pas se baser sur cette exception pour savoir s'il l'association à sens unique est activée ou non.
Exception: type = '<type 'exceptions.AttributeError'>', value = 'User hash is not enabled' Stack trace (most recent call first): File "/home/thomas/dev/au-quoditien/wcs/wcs/users.py", line 55, in get_hash 53 identification_cfg = get_cfg('identification', {}) 54 if not identification_cfg.get('use_user_hash'): > 55 raise AttributeError('User hash is not enabled') 56 secret_key = identification_cfg.get('user_hash_secret_key') 57 if not secret_key: locals: self = <wcs.users.User object at 0x33ec210> identification_cfg = {'user_hash_secret_key': '9814760411681449466', 'methods': ['password'], 'use_user_hash': False} File "/home/thomas/dev/au-quoditien/wcs/wcs/formdata.py", line 287, in is_submitter 285 if self.user_id and self.user_id == user.id: 286 return True > 287 if self.user_hash and self.user_hash == user.hash: 288 return True 289 return False locals: self = <wcs.formdef.Cantine object at 0x35ba490> user = <wcs.users.User object at 0x33ec210> File "/home/thomas/dev/au-quoditien/wcs/wcs/forms/common.ptl", line 69, in check_auth 67 if len(anonylink) == 1: 68 mine = True > 69 elif self.filled.is_submitter(user): 70 mine = True 71
Historique
Mis à jour par Frédéric Péters il y a environ 12 ans
- Assigné à mis à Thomas Noël
Vu pendant l'eocamp,.
Mis à jour par Thomas Noël il y a presque 12 ans
Réflexion à mener en parallèle, je pense : ne pas utiliser un user_hash global (qui permet facilement les recoupements entre formulaires) ; prévoir plutôt un hash fonction du formdef...?
Mis à jour par Benjamin Dauvergne il y a presque 12 ans
redmine@entrouvert.com écrivait:
La demande #1276 a été mise à jour par Thomas Noël.
Réflexion à mener en parallèle, je pense : ne pas utiliser un
user_hash global (qui permet facilement les recoupements entre
formulaires) ; prévoir plutôt un hash fonction du formdef...?
Billevesée que tout cela :) Le plus normal serait de simplement garder
la liste des 'formdef.id#formdata.id' dans l'objet user ou un objet
à part éventuellement, et rien dans le formdata. Tous ces hash sont bien
inutiles et ne servent qu'à rassurer les fantasmes de la CNIL. Si le
système actuel leur suffit et est le plus simple à implémenter je serai
d'avis de ne pas aller plus loin.
Mis à jour par Thomas Noël il y a presque 12 ans
- Version cible changé de 81 à Au-quotidien 2012.3
Mis à jour par Thomas Noël il y a plus de 11 ans
- Version cible changé de Au-quotidien 2012.3 à Au-quotidien 2014.5
Pas critique actuellement ; faudra que je re-reflechisse à ça un peu plus tard... (d'où cible 2012.4)
Mis à jour par Frédéric Péters il y a plus de 11 ans
- Statut changé de Nouveau à Résolu (à déployer)
En oubliant qu'il y avait ce ticket, je suis tombé sur l'exception, et j'ai corrigé vite fait en passant; pour des évolutions à l'user hash, on verra dans d'autres tickets.
commit 72c2429708d57d7049ea07d6f62ea42310a826a0 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Sun Nov 11 19:00:54 2012 +0100 do not fail on checking for submitter when user hashes get disabled