Development #54525
inclure l'expiration de session d'un utilisateur dans le journal (?)
0%
Description
Dans un ticket de support (#54523), à propos d'une action aujourd'hui :
d’autant plus par une utilisatrice qui ne s'est pas connectée aujourd'hui :
Elle peut très bien avoir utilisé une session déjà ouverte, cf le journal, on voit bien qu'il n'y a pas eu de déconnexion explicite.
De là je me dis que ça aurait pu être pratique de pointer dans le journal qu'il n'y avait pas de ligne "déconnexion par expiration de session".
Related issues
History
Updated by Benjamin Dauvergne over 2 years ago
Ce n'est pas évident à faire, il faut monkeypatcher django.contrib.sessions.backends.db.clear_expired pour récupérer les vrais évènements. Pour le fond du sujet je ne trouve pas ça utile, jamais vu un logiciel qui log les expirations implicites de session, surtout qu'ici ça ne produit rien (si encore on en profitait pour envoyer des SLO ou que sais-je... mais authentic ne fait pas ça).
Updated by Paul Marillonnet over 2 years ago
- Related to Development #55580: idp_oidc : gestion de la déconnexion unique backchannel initiée par authentic en tant que fournisseur oidc added
Updated by Paul Marillonnet over 2 years ago
Updated by Paul Marillonnet over 2 years ago
- Related to Development #55581: déconnexion unique initiée par authentic en tant que fournisseur d’identité sur expiration de la session added
Updated by Frédéric Péters over 2 years ago
Pour le fond du sujet je ne trouve pas ça utile.
En l'espèce la description du ticket reprend le cas directement utile, qui aurait été de déterminer que la personne avait encore une session ouverte à un moment.
Mais je posais l'interrogation dans le sujet du ticket, si pour peu importe la raison, on ne veut pas, so be it.
Updated by Benjamin Dauvergne over 2 years ago
Frédéric Péters a écrit :
En l'espèce la description du ticket reprend le cas directement utile, qui aurait été de déterminer que la personne avait encore une session ouverte à un moment.
Oui pas de souci, j'indique comment faire justement. Je dis juste, et la lecture du ticket pointé me le confirme parce que ça n'a pas de rapport, que ce sera rarement utile, l'information du dernier SSO vers w.c.s. suffit par exemple, la durée des sessions étant fixé à l'attribute sessionNoOnOrAfter coté w.c.s. qui par défaut vaut now() + SESSION_COOKIE_AGE, les sessions coté w.c.s. ne peuvent pas être plus vieille que ça (après le bouton remember ne s'il est activé, peut jouer un rôle, c'est peut-être d'ailleurs une erreur).