Project

General

Profile

Development #54525

inclure l'expiration de session d'un utilisateur dans le journal (?)

Added by Frédéric Péters 4 months ago. Updated 3 months ago.

Status:
Nouveau
Priority:
Normal
Category:
-
Target version:
-
Start date:
02 Jun 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

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

Related to Authentic 2 - Development #55580: idp_oidc : gestion de la déconnexion unique backchannel initiée par authentic en tant que fournisseur oidcNouveau13 Jul 2021

Actions
Related to Authentic 2 - Development #55581: déconnexion unique initiée par authentic en tant que fournisseur d’identité sur expiration de la sessionNouveau13 Jul 2021

Actions

History

#1

Updated by Paul Marillonnet 3 months ago

  • Assignee set to Paul Marillonnet
#2

Updated by Benjamin Dauvergne 3 months 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).

#3

Updated by Paul Marillonnet 3 months ago

  • Related to Development #55580: idp_oidc : gestion de la déconnexion unique backchannel initiée par authentic en tant que fournisseur oidc added
#4

Updated by Paul Marillonnet 3 months ago

(Mes souvenirs sont vagues mais il me semble qu’on gère déjà les bindings synchrones SAML2 de SLO initié par a2 en tant qu’IdP, cependant #55580 et #55581 pour garder trace de l'idée.)

#5

Updated by Paul Marillonnet 3 months ago

  • Related to Development #55581: déconnexion unique initiée par authentic en tant que fournisseur d’identité sur expiration de la session added
#6

Updated by Frédéric Péters 3 months 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.

#7

Updated by Benjamin Dauvergne 3 months 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).

Also available in: Atom PDF