Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • A AuthENS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 6
    • Issues 6
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Klub Dev ENSKlub Dev ENS
  • AuthENS
  • Issues
  • #1
Closed
Open
Issue created May 11, 2020 by Martin Pepin@mpepinOwner

Discussion : proposition d'alternative à django-allauth-ens

Contexte

On a besoin un peu partout d'auth CAS + exté, typiquement sur gestioCOF, le gestioBDS à venir, l'annuaire, le wiki, etc. django-allauth-ens propose cette fonctionnalité et gère les conflits de username entre comptes extés existants et comptes clippers. Il est possible aussi de gérer la non-unicité des clippers, i.e. le fait que rien n'empêche le SPI de redonner un jour des logins clipper ayant déjà été utilisé par le passé.

Problèmes :

  • django-allauth-ens est intégré avec django-allauth qui est une usine à gaz
  • utiliser django-allauth-ens est tout sauf simple
  • la gestion de la non-unicité des clippers implique une intervention manuelle tous les ans et est buguée django-allauth-ens#6

Proposition alternative à allauth-ens

Le but de ce dépôt est d'essayer de reprendre les bonnes idées de django-allauth-ens dans une lib plus simple à utiliser et sans la dépendance à allauth. C'est volontairement moins générique pour tenir en peu de lignes code et pouvoir être compris et utilisé facilement.

C'est encore un prototype. J'ouvre cette issue tôt pour avoir un retour critique et une discussion sur le design de base et/ou sur la pertinence de recoder un module d'auth pour l'ENS. Autrement dit, lâchez vous.

Design

On maintient une table Clipper qui lie des Users Django à un login clipper et une année d'entrée à l'ENS:

class Clipper(models.Model):
    user = models.OneToOneField(User, ...)
    uid = models.CharField(...)  # aka le login clipper
    entrance_year = models.SmallIntegerField(...)

Ça permet deux choses :

  • le username d'une personne n'a pas a être égal à son login clipper → si un username est déjà pris quand on veut inscrire quelqu'un avec un clipper, c'est pas grave.
  • le entrance_year permet de lever l’ambiguïté dans le cas théorique où le SPI décide de réutiliser des vieux logins clipper un jour.

Authentification

On ajoute un backend d'auth qui connecte par cas en utilisant le champ uid de cette table plutôt que User.username. À chaque connexion, le CAS nous donnes assez de métadonnées pour connaître la promo de la personne, on en profite pour vérifier que le compte clipper qu'on connaît est toujours valide, c'est à dire si le entrance_year qu'on a stocké correspond à la promo.

Création manuelle d'Users

Je n'ai pas encore écrit le helper pour faire ça mais quand on veut créer manuellement un User avec un login clipper, il faut ajouter une entrée dans la table Clipper et aller chercher le numéro de promo dans le ldap.

Choix discutables ?

  • Recoder un truc from scratch plutôt qu'essayer d'améliorer django-allauth-ens ?

  • Je n'ai pas utilisé django_cas_ng et j'ai recodé un petit backend d'auth.

    • pour : c'est assez simple grâce à python-cas (je ne l'aurais pas fait sinon)
    • pour : ça évite d'avoir à configurer django_cas_ng quand on utilise AuthENS
    • pour : je n'étais pas sûr de pouvoir faire tout ce que je voulais avec django_cas_ng
    • contre : c'est dommage de recoder un CAS alors que django_cas_ng existe
    • contre : en fait c'est peut-être possible de faire la même chose en utilisant bien les options de django_cas_ng, il faut que je regarde
    • question : django_cas_ng maintient une table de tickets qu'il n'a pas l'air d'utiliser, à quoi ça sert à part savoir qui est connecté ? Est-ce qu'on a besoin de ça ?

TODO

  • Fournir un script pour migrer d'une install sans AuthENS → avec AuthENS ?
  • Gérer les adresses emails : ajouter un user.email = "{}@clipper.ens.fr".format(uid) quelque part
  • J'ai oublié le .strip().lowercase()
  • Formulaire de récupération de mot de passe
  • Faire des vrais templates :
    • avec du CSS
    • avec du texte explicatif sur les méthodes de connexion
  • Indiquer au logout qu'on est déconnecté du site mais pas de CAS. Si on n'aime pas de comportement on peut aussi déconnecter les gens du CAS

Liens pertinents

  • doc python-cas : https://djangocas.dev/docs/latest/modules/python_cas.html
  • doc de django-cas-ng : https://djangocas.dev/docs/latest/index.html
  • doc Django de l'auth "custom" : https://docs.djangoproject.com/en/3.0/topics/auth/customizing/
Edited Apr 13, 2021 by Martin Pepin
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking