Authentification via django-allauth #578
No reviewers
Labels
No labels
devtype -- backend
devtype -- docs
devtype -- frontend
devtype -- user interface
difficulty -- easy
difficulty -- hard
difficulty -- normal
Doing
domain -- bda
domain -- bds
domain -- cof
domain -- core
domain -- kfet
Good first issue
priority -- high
priority -- low
priority -- medium
priority -- staff-wanted
status -- development
status -- discussion
status -- need review
status -- production
status -- ready to merge
status -- todo
To Do
type -- bug
type -- hygiene
type -- improvement
type -- new feature
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/gestioCOF#578
Loading…
Reference in a new issue
No description provided.
Delete branch "aureplop/install-authens"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Important : Avant d'appliquer les nouvelles migrations à une BDD déjà existante, il faut s'assurer de l'unicité des
CofProfile.login_clipper
, et éventuellement fusionner les comptes problématiques.Todos
Remarques
Déploiement
Description
Modes de connexion disponibles
User
.https://cas.eleves.ens.fr
).Un compte est créé automatiquement si l'identifiant n'est pas déjà associé à un utilisateur, l'id est alors utilisé comme
username
(ou un dérivé s'il est déjà utilisé),<clipper_id>@clipper.ens.fr
est utilisé comme email.Refer to allauth doc for an accurate features list:
http://django-allauth.readthedocs.io/en/latest/
one if they don't have one. Fixes #177.
clipper authentication to configure a password before losing their
clipper. Even if they have already lost it, they are able to get one
using the "Reset password" functionality.
related url redirect to the home page.
also concerns the Django and Wagtail admin sites.
they authenticated via this server. Instead a message suggests the user
to disconnect.
Clipper connections and
login_clipper
login_clipper
are now unique amongCofProfile
instances.the data migration 0014_create_clipper_connections).
login_clipper
of CofProfile instances are sync with theirclipper connections:
CofProfile.sync_clipper_connections
method updates theconnections based on
login_clipper
.sync_clipper…
updatelogin_clipper
based onconnections creations/updates/deletions.
Misc
unique=True
onCharField (even with empty strings).
as they are used elsewhere than in the kfet app.
added 2 commits
Compare with previous version
changed the description
added 9 commits
master
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
mentioned in merge request !280
@mpepin @champeno faut en discuter sérieusement de ça, c'est un poil risqué entre les migrations à faire & co
On fait ça un matin/une aprem prochainement ? On part pas tant que c'est pas deploy en prod, seems legit ?
added ~62 ~64 ~30 ~26 labels
C'est #190 qui nous dit de fix les doublons de
login_clipper
, et donc des doublons deUser
& cie :-(mentioned in merge request !261
mentioned in issue #190
mentioned in issue #178
mentioned in issue #177
Mauvaise nouvelle : on a 5 doublons alors que j'avais fait le vide. Ça veut dire que ça revient et je ne sais pas trop pourquoi…
NB: commande python pour récupérer la liste des doublons :
added 160 commits
master
Compare with previous version
added 3 commits
Compare with previous version
changed the description
added 3 commits
Compare with previous version
added 3 commits
Compare with previous version
added 11 commits
master
Compare with previous version
J'ai push -f : rebase master, résolution de conflits en tout genre, commit blackifiés, rebase master
Y'a pu y avoir des erreurs. Faudrait que je vérifie...
added 3 commits
Compare with previous version
added 3 commits
Compare with previous version
added 3 commits
Compare with previous version
added 3 commits
Compare with previous version
J'observe le même problème que sur GestioPEI et WikiENS, je commence à penser qu'il y a un problème du côté de
django-allauth-cas
oupython-cas
:Pour info le xml dont le parsing échoue est la page d'accueil du cas.
Une requête doit être mal faite à un endroit pour qu'on reçoive ça au lieu d'un ticket
added 15 commits
master
05eeb6a2
- core -- Install django-allauth-ense56200a5
- kfet -- LoginGenericView directly disconnects users.030a0237
- Fix & clean login/logout urlsCompare with previous version
added 1 commit
a4be431c
- core.ci -- Add dependencies for LDAP stuffCompare with previous version
C'est update avec django-allauth-ens 1.1.1, qui fixe le problème exposé par @mpepin.
Reste à passer au LongTermAdapter. On peut le faire en 2 parties non : merge ça, puis passer au LongTermAdapater dans une autre PR.
Un avis @champeno sur ce changement (l'adapter) ?
On part sur une nouvelle installation de allauth avec script qui crée des connexions à partir des infos déjà connues (des login clipper seulement). Sans toucher à la migration, je crois qu'on peut lancer la MAJ du code en prod avec la migration, puis run la commande de
allauth-ens
pour convertir vers le nouveau système.Pour la migration, le LongTermAdapter faut tout en un avec
python manage.py install_longterm
(la création des connexions quand un clipper existe et le remplissage des infos ldap). Donc c'est peut-être plus pertinent de l'utiliser non ?Ah pardon, j'ai cru que y'avait que la partie "auth-ens sans longterm" → "auth-ens avec longterm".
Question du coup : où
install_longterm
récupère le login clipper d'un utilisateur ?Il suppose que c'est le username https://git.eleves.ens.fr/cof-geek/django-allauth-ens/blob/master/allauth_ens/adapter.py#L156
@mpepin t'as rendu unique la colonne CofProfile.login_clipper ?
@champeno Si oui, comment ça se passe si on laisse la migration faire la partie CofProfile.login_clipper → SocialAccount, et install_longterm la partie qui ajoute la promo en demandant au LDAP ? (Est-ce que ça tente encore de créer des SocialAccount à partir des username ?)
Ou alors on remplace les usernames par les login clipper mais ça semble plus hardcore que d'éventuellement ajouter un flag pour désactiver le comportement évoqué juste au-dessus.
Euh hum visiblement mon code va créer des SocialAccount à partir des usernames, cf https://git.eleves.ens.fr/cof-geek/django-allauth-ens/blob/master/allauth_ens/adapter.py#L189
Je peux rajouter un paramètre à la commande qui dise quel champ utiliser à
install_longterm
(username ou cofprofile.login_clipper ou autre) éventuellement ? Comme ça tout roule direct.@champeno J'ai ouvert le lien :P Effectivement, on peut lui mettre un paramètre pour lui dire de manger les username ou bien les
SocialAccount.objects.filter(provider="clipper").values("uid")
par exemple ?On pourrait éventuellement affiner le premier en lui donnant un moyen de customiser le getter, mais le second cas a l'air pratique pour d'éventuelles autres migrations "auth-ens sans longterm" → "auth-ens avec longterm".
Je linkais pas la même ligne ^^. Dans la pratique on va plus souvent vouloir faire django-cas -> allauth+longterm que allauth -> allauth+longterm non ?
Enfin sinon on mets un flag
--use-socialaccounts
pour un cas et un paramètre--clipper-field
pour l'autre ?A priori plus de nouvelles installations devraient avoir de django-cas, donc je pense que le second cas risque plus d'arriver.
Sinon va pour ces flags. Tu t'en occupes ou j'y vais ?
Je fais ça en vitesse :)
Non on a toujours des problèmes de doublons, apparus récemment, que je n'ai pas réglés.
Pour éviter les mauvaises surprises, la migration pourrait, avant de commencer à faire des modifs dans la bdd, checker qu'il n'y a plus de doublons et crasher si c'est le cas. Ça vous parrait overkill ?
Je peux écrire le bout de code qui fait ça
La migration 0015 passe CofProfile.login_clipper en unique=True, donc elle plantera si y'a problème.
Faudra revert le commit de merge ou corriger et réessayer si besoin.
Ah mais attends,
install_longterm
renomme les username de tous les Users concernés parclipper@promo
. Est-ce qu'on veut ça sur gestioCOF ?mentioned in merge request django-allauth-ens!18
https://git.eleves.ens.fr/cof-geek/django-allauth-ens/merge_requests/18 @delobell
Bien vu pour le username modifié aussi. Un flag en plus ?
Voilà~
@champeno On peut quand même se faire cette transition sans longterm ? Comme ça on passe déjà ça :)
On voit l'installation de longterm ensuite.
@mpepin Tu peux donner les différentes étapes pour fusionner les doublons de compte ?
Je peux aller me les faire ;)
Hmmm je crois que si on fait ça il faut créer tous les
SocialAccount
à la main quand même, sinon les gens ne pourront pas se connecter (ce qui revient à peu de choses près à faireinstall_longterm
)Pour avoir fait la transition cas -> allauth sur ExperiENS pendant ces vacances, ça marchait correctement, à un détail près : le compte
conscrit
qui n'a pas de promo (il suffit de le supprimer ou de changer son username)On a déjà ça en fait :
a4be431c4f/gestioncof/migrations/0016_create_clipper_conns.py
Ah oui. Il y a un truc qu'on ne fait pas d'ailleurs (et qu'il serait bien de faire) : créer les
EmailAddress
(initialisées avec les adresses clipper)Alors côté GestioCOF, on utilise pas les
EmailAddress
. On s'évite un peu de complexité comme ça.J'espère que ça va pas nous porter préjudice, mais je crois qu'on peut s'en passer.
Allauth les utilise pas pour les "mot de passe oublié" ? Mais du coup ça ne servira que pour les auths non-clipper.
allauth utilise l'adresse donnée par l'utilisateur dans le formulaire :
https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L510
et https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L539
Pour savoir si l'utilisateur correspond à un email, il prend en compte les
EmailAddress
mais aussi lesUser.email
:https://github.com/pennersr/django-allauth/blob/master/allauth/account/utils.py#L386
https://github.com/pennersr/django-allauth/blob/master/allauth/account/app_settings.py#L238
Donc on a l'air bon
copy-paste depuis merle :
Il faut commencer par chercher la liste des doublons :
Ensuite tu te mets superuser, tu vas dans l'admin
Si t'as de la chance, il y a un compte avec rien dessus (pas statut COF, pas d'événements, de tirages etc), auquel cas faut juste le virer et vérifier que le compte qui reste a
username == clipper
Si t'as pas de bol, il y aura des événements / sondages attachés aux deux comptes et il faudra dans un shell python basculer tout sur un compte avant de supprimer l'autre
pour savoir tu cliques sur "supprimer" dans l'admin et dans la fenêtre de confirmation il te dit ce qui risque d'être supprimé en cascade
mentioned in merge request !346
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.