Bug #47818
crash user vide dans la request
0%
Description
Exception:
type = '<class 'AttributeError'>', value = ''NoneType' object has no attribute 'id''
Stack trace (most recent call first):
File "/usr/lib/python3/dist-packages/wcs/forms/root.py", line 1211, in submitted
1209 session = get_session()
1210 if session and session.user and not str(session.user).startswith('anonymous-'):
> 1211 filled.user_id = get_request().user.id
1212
1213 if get_request().get_path().startswith('/backoffice/'):
locals:
existing_formdata = None
filled = <Simulateur-De-Demande-D-Allocation-Personnalisee-Dautonomie-Apa "Simulateur de demande d'Allocation Personnalisée d'Autonomie
(APA) - n°42-1618" id:1618>
form = <wcs.qommon.form.Form object at 0x7f2b210eea58>
self = <modules.formpage.AlternateFormPage object at 0x7f2b20e875f8>
session = <Session at 7f2b2198ceb8: 2yOn8Aa7AUaeV5JimK4I5Q>
C'est bien curieux normalement si c'est dans la session ça doit aussi être dans get_request().
À inspecter les choses, la session existait encore mais l'utilisateur avait entretemps été supprimé /
'email': '...@yahoo.fr#8896552', 'is_admin': False, 'anonymous': False, 'lasso_dump': None, 'last_seen': 1602955532.0, 'deleted_timestamp': None, 'is_active': False,
puis recréé dans la foulée :
- https://connexion.e-service.seine-et-marne.fr/admin/custom_user/user/1769/change/ (supprimé)
- https://connexion.e-service.seine-et-marne.fr/admin/custom_user/user/1770/change/ (recréé, même email autre nom)
Mais j'aurais pensé qu'une suppression déclenchait la déconnexion globale, visiblement pas, ou en tout cas faut pas compter dessus.
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Fichier 0001-sessions-unset-disabled-deleted-user-from-session-47.patch 0001-sessions-unset-disabled-deleted-user-from-session-47.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a plus de 3 ans
- Statut changé de Solution proposée à Solution validée
« la session existait encore mais l'utilisateur avait entretemps été supprimé puis recréé dans la foulée » ah ouais quand même, good catch. Et code facile, go.
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 6ce2b1efac9bff5cc5d9f6e49fdf4fb58a8dbf14
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Oct 17 20:14:02 2020 +0200
sessions: unset disabled/deleted user from session (#47818)
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Frédéric Péters a écrit :
Mais j'aurais pensé qu'une suppression déclenchait la déconnexion globale, visiblement pas, ou en tout cas faut pas compter dessus.
C'est le cas mais uniquement si on est dans une session du même utilisateur :
logger.info(u'deletion of account %s performed', self.user)
hooks.call_hooks('event', name='delete-account', user=self.user)
request.journal.record('user.deletion', user=self.user)
if self.user == request.user:
# No validation message displayed, as the user will surely
# notice their own account deletion...
return logout(request, check_referer=False)
si la personne ferme son navigateur puis revient, ouvre le mail et clique, on peut penser que la session initiale est perdue (avec des sessions "EXPIRE_AT_BROWSER_CLOSE"). Mais c'est aussi possible que la déconnexion d'un utilisateur supprimé sur w.c.s. ne marche pas, je doute qu'on ait un test sur ce cas précis.
Si ça ne vient pas du processus de SLO lui même il faudrait rajouter une fermeture des autres sessions avec SLO asynchrone vers les services où c'est possible pour corriger ça.
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
sessions: unset disabled/deleted user from session (#47818)