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".
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
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).
Mis à jour par Paul Marillonnet il y a presque 3 ans
- Lié à Development #55580: idp_oidc : gestion de la déconnexion unique backchannel initiée par authentic en tant que fournisseur oidc ajouté
Mis à jour par Paul Marillonnet il y a presque 3 ans
Mis à jour par Paul Marillonnet il y a presque 3 ans
- Lié à Development #55581: déconnexion unique initiée par authentic en tant que fournisseur d’identité sur expiration de la session ajouté
Mis à jour par Frédéric Péters il y a presque 3 ans
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.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
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).