Project

General

Profile

Bug #47818

crash user vide dans la request

Added by Frédéric Péters 11 days ago. Updated 9 days ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
17 Oct 2020
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

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 :

Mais j'aurais pensé qu'une suppression déclenchait la déconnexion globale, visiblement pas, ou en tout cas faut pas compter dessus.

0001-sessions-unset-disabled-deleted-user-from-session-47.patch View (2.75 KB) Frédéric Péters, 17 Oct 2020 08:29 PM

Associated revisions

Revision 6ce2b1ef (diff)
Added by Frédéric Péters 10 days ago

sessions: unset disabled/deleted user from session (#47818)

History

#1 Updated by Frédéric Péters 11 days ago

#2 Updated by Thomas Noël 10 days ago

  • Status changed from Solution proposée to 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.

#3 Updated by Frédéric Péters 10 days ago

  • Status changed from Solution validée to 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)

#4 Updated by Benjamin Dauvergne 10 days ago

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.

#5 Updated by Frédéric Péters 9 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF