Produits Entr'ouvert » Authentic 2

C'est peut-être un peu #20695 (mais il me semble plus concerner le backoffice).

Il faut regarder du coté de https://github.com/Bouke/django-user-sessions/.

1. comparer ça avec le code actuel en django 1.11 voir s'ils opèrent bien toutes les vérifications de sécurité présente dans Django
2. vérifier que c'est bien compatible avec les backend CachedDb et sinon en développer un

Il faut regarder du coté de https://github.com/Bouke/django-user-sessions/.

Il me semble (mais juste 5 minutes) que ça concerne les sessions courantes, alors que (cf capture gitlab.png) ici je verrais aussi un côté historique. (pour ça que je parlais du côté journal #20695 dans mon commentaire).

• des sessions en base avec une colonne explicite pour l'utilisateur et diverses informations sauvegardées comme le navigo et l'IP
• un historique des connexion conservant ces mêmes informations, il faudra aussi conserver le numéro de session (ou un hash) pour pouvoir faire la jointure entre les deux à l'affichage

Il faudra exporter ces informations via une API aussi dans l'objectif de déporter les choses dans combo (on va dire que ce ticket est un ticket chapeau et il faudra des sous tickets pour les différents éléments).

Benjamin Dauvergne a écrit :

Oui pour atteindre l'objectif github il faudra deux choses:

• des sessions en base avec une colonne explicite pour l'utilisateur et diverses informations sauvegardées comme le navigo et l'IP
• un historique des connexion conservant ces mêmes informations, il faudra aussi conserver le numéro de session (ou un hash) pour pouvoir faire la jointure entre les deux à l'affichage

Et du coup, si on a besoin de toutes ces informations et de la jointure, c'est bien on reprendrait un affichage similaire à la capture gitlab, mais avec en plus une liste de connexions pour chaque session ?
Du genre :

• Session 1 :
  • Navigateur : Firefox 61
  • Adresse IP : 1.2.3.4
  • Localisation : Paris, France
  • Connexions :
    • Le 7 août à 17h30
    • Le 4 juillet à 21h53

• Session 2 :
  • Navigateur : Chromium 68
  • Adresse IP : 5.6.7.8
  • Localisation : Panama, République du Panama
  • Connexions :
    • Le 4 août à 16h33

Je me plante ? Ou c'est bien de ça qu'on parle ?

Ah oui, encore autre chose : si on propose la possibilité de supprimer une session, est-ce que ça se passe directement et complètement sur cette page ? Ou bien est-ce que, comme le réinitialisation de mot de passe, il ne vaut pas mieux envoyer un mail contenant un lien avec un jeton de validation ?

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Oui pour atteindre l'objectif github il faudra deux choses:

• des sessions en base avec une colonne explicite pour l'utilisateur et diverses informations sauvegardées comme le navigo et l'IP
• un historique des connexion conservant ces mêmes informations, il faudra aussi conserver le numéro de session (ou un hash) pour pouvoir faire la jointure entre les deux à l'affichage

Et du coup, si on a besoin de toutes ces informations et de la jointure, c'est bien on reprendrait un affichage similaire à la capture gitlab, mais avec en plus une liste de connexions pour chaque session ?
Du genre :

Je ne vois pas comment on peut avoir plusieurs connexion par session (à part des trucs zarbis comme je suis connecté en login/mdp puis je me reconnecte via certificat pour augmenter mon niveau de sécurité, la session aura quand même démarré à la première connexion).

Je me plante ? Ou c'est bien de ça qu'on parle ?

C'est l'idée oui.

On récupère la liste des sessions en cours, disons dans sessions un dico indexé par les identifiants de session.

On doit parcourir les dernières connexion dans l'ordre horaire inverse et quand le numéro de session correspond à une dans sessions on l a marque comme active.

Paul Marillonnet a écrit :

Ah oui, encore autre chose : si on propose la possibilité de supprimer une session, est-ce que ça se passe directement et complètement sur cette page ? Ou bien est-ce que, comme le réinitialisation de mot de passe, il ne vaut pas mieux envoyer un mail contenant un lien avec un jeton de validation ?

Oui ça se passe sur cette interface, on ne doit pas pouvoir supprimer sa propre session, non pas besoin de validation, on ne touche pas au fonction de sécurité en faisant cela (contrairement au fait de changer un mot de passe par exemple).

Dans le cas courant il me semble que l'usager n'a qu'une session, celle avec laquelle il consulte cette page. A moins que l'usager soit simultanément connecté avec plusieurs terminaux. Mais je ne suis pas sûr de la pertinence d'afficher cette information plutôt technique à l'usager.

L'historique des connexions est lui très pertinent. Il s'inscrit dans la fonctionnalité journal du compte dans lequel figurerait également toutes les opérations de modifications, suspension, changement de mot le passe, etc. faites par l'usager ou un agent. Il s 'agit de l'objet de la demande #21971.

Et donc, peut-être, pour corriger mon erreur dans ma dernière intervention, faire apparaître un écran de la forme :

Session 1 (session en cours) :
        Navigateur : Firefox 61
        Adresse IP : 1.2.3.4
        Localisation : Paris, France
        Dernière connexion : Maintenant

Session 2 :
        Navigateur : Chromium 68
        Adresse IP : 5.6.7.8
        Localisation : Panama, République du Panama
        Dernière Connexion : Samedi 4 août à 16h33

Mais du coup, Mikaël, je ne comprends plus ce que tu entends par connexion.
Est-ce une étape explicite d'authentification, ou bien la consultation d'une page quelle qu'elle soit lorsque l'usager est authentifié ?

Oui, connexion au sens session authentifiée quelque soit la méthode d'authentification. Cela correspondrait donc bien à la liste des sessions authentifiées, ouvertes ou fermées, si ce n'est que le terme session ne sera je pense pas compris par l'usager qui est plus familier du terme connexion.

Je ne comprend cependant pas le fait que plusieurs connexions soient attachées à une même session.

Dans le détail des informations de connexion il faut ajouter la méthode de connexion (mot de passe, FC, fournisseur d'identité X,) éventuellement ajouter aussi le service de destination si la connexion se fait dans une phase de sso.

• Connexion via mdp/FC/... le ... depuis le terminal ... IP .....
• Connexion via mdp/FC/... le ... depuis le terminal ... IP .....

On retrouve ce type d'info par exemple ici : https://moncompte-rec.grandlyon.com/manage/users/29/actions-journal/

J'imagine que la demande de Fred vient de la fonctionnalité apportée par la case à cocher "remember me" qui fait que l'on a maintenant des sessions usagers qui vont persister au dela de la journée et de la fermeture du navigo. Et là je me dis qu'effectivement il faut permettre à l'usager de les révoquer s'il utilise plusieurs terminaux, comme sur les captures d'écran fournies. Je me demande s'il n'est pas préférable de scinder d'un côté le journal du compte qui inclus l'historique des connexions et d'un autre un espace dédié à la fermeture des sessions actives.

Mikaël Ates a écrit :

Oui, connexion au sens session authentifiée quelque soit la méthode d'authentification. Cela correspondrait donc bien à la liste des sessions authentifiées, ouvertes ou fermées, si ce n'est que le terme session ne sera je pense pas compris par l'usager qui est plus familier du terme connexion.

Ok.

Je ne comprend cependant pas le fait que plusieurs connexions soit attachées à une même session.

Oui, erreur de ma part.

Dans le détails des informations de connexion il faut ajouter la méthode de connexion (mot de passe, FC, fournisseur d'identité X,) éventuellement ajouter aussi le service de destination si la connexion se fait dans une phase de sso.

• Connexion via mdp/FC/... le ... depuis le terminal ... IP .....
• Connexion via mdp/FC/... le ... depuis le terminal ... IP .....

Ok je pars là-dessus.

On retrouve ce type d'info par exemple ici : https://moncompte-rec.grandlyon.com/manage/users/29/actions-journal/

J'imagine que la demande de Fred vient de la fonctionnalité apportée par la case à cocher "remember me" qui fait que l'on a maintenant des sessions usagers qui vont persister au dela de la journée et de la fermeture du navigo. Et là je me dis qu'effectivement il faut permettre à l'usager de les révoquer s'il utilise plusieurs terminaux, comme sur les captures d'écran fournies. Je me demande s'il n'est pas préférable de scinder d'un côté le journal du compte qui inclus l'historique des connexions et d'un autre un espace dédié à la fermeture des sessions actives.

Ok (et donc sans doute faire un ticket à part pour ce qui est de la fermeture des sessions ?)

Mikaël Ates a écrit :

On retrouve ce type d'info par exemple ici : https://moncompte-rec.grandlyon.com/manage/users/29/actions-journal/

Je vais aussi chercher si cette vue 'actions-journal' est dans une branche spécifique au GLC.
(Parce que je n'ai pas accès à cette plateforme, je ne peux pas voir l'exemple en live)

Benjamin Dauvergne a écrit :

Il faut regarder du coté de https://github.com/Bouke/django-user-sessions/.

Est-ce une dépendance qu'on peut se permettre d'ajouter à A2, ou bien c'est juste pour le coup d'œil ?

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Il faut regarder du coté de https://github.com/Bouke/django-user-sessions/.

Est-ce une dépendance qu'on peut se permettre d'ajouter à A2, ou bien c'est juste pour le coup d'œil ?

C'est à déterminer, si l'utilisation de ce truc est indolore en combinaison avec CachedDb (on utilise généralement un memcache/redis + des sessions en base, on veut continuer comme cela), go.

Depuis les dernières notes de ce ticket il y a des choses plus récentes genre https://github.com/QueraTeam/django-qsessions qui montrent le caractère assez contenu de l’affaire, et qui reposent très largement sur le fait de désanonymiser les sessions déjà existantes dans django et de spécifier un peu le comportement de django.contrib.sessions.backends.cached_db en tant que moteur de session par défaut django (setting SESSION_ENGINE).