Remplace la vue de login par la LoginView de Django

[Arnaud-D]

Un des items de #6246.
Fix #4861 .

Refactorisation des tests du login :

• réorganisation des tests existants
• ajout d'un test pour vérifier que l'erreur obtenue pour un utilisateur inactif est la bonne
• correction d'un bug dans la vue pour passer le test (c'est ce soucis-là : fix Renvoyer l'email de confirmation et afficher une alerte à la connexion #5371)

Refactorisation du login lui-même :

• utilise la LoginView de Django
• change le backend standard pour afficher une erreur spécifique pour les comptes inactifs (nécessaire en utilisant la LoginView de Django, par défaut les comptes inactifs ratent le test d'authentification, ce qui fait directement une erreur login/password et pas celle de compte inactif) ;
• simplifie en fusionnant les erreurs pour mauvais nom d'utilisateur ou mot de passe (standard partout pour éviter d'informer un attaquant éventuel ; l'avantage est limité chez nous puisque qu'on se logue par pseudo, rapidement public et pas par email) ;
• conserve le comportement de redirection originel

Quelques tests supplémentaires :

• rajouter un test pour le "remember me"
• rajouter un test pour le bon enregistrement de l'IP

Contrôle qualité

Ces choses-là sont faites aussi dans les tests unitaires, mais on peut tester à la main aussi :

• Se loguer normalement avec un compte actif (n'importe lequel des fixtures fait l'affaire).
• Tenter de se loguer avec un mauvais utilisateur, puis mauvais mot de passe et constater la même erreur dans les deux cas.
• Bannir compte et constater une erreur spécifique quand on tente de se loguer avec
• créer un compte inactif (admin, puis créer un user, puis créer un profile associé, bien mettre le user inactif), tenter de se loguer et constater l'erreur adéquate
• jouer avec l'option "se souvenir de moi" et constater que le cookie de session est bien réglé avec les outils de dév
• constater les bonnes redirections avec le paramètres 'next' (notamment : la page indiquée si elle existe, la homepage au lieu de retourner sur le login/inscription/déconnexion, ou la homepage de manière générale en cas de soucis)

En plus, il serait sûrement souhaitable de vérifier que l'authentification par Google et Facebook marche, mais ça ne fonctionne pas du tout en local chez moi, que ce soit cette PR ou même avant ça.

[coveralls]

Coverage increased (+0.008%) to 88.087% when pulling 4f2a440 on Arnaud-D:django_loginview into d585f02 on zestedesavoir:dev.

[Arnaud-D]

C'est prêt à être QA !

[Arnaud-D]

D'après le commentaire de Migwel dans l'issue ci-dessus : fix #4861.

[philippemilink]

Tu peux mettre à jour la PR et corriger le conflit, stp ?

[philippemilink]

Quelques petits détails à corriger et ça devrait être bon.

[philippemilink]

Tout fonctionne bien, sauf la redirection vers l'URL quand on se connecte.

Pour reproduire :

1. Se connecter
2. Aller sur une page à laquelle on ne peut accéder qu'en étant connecté (éditer un message sur le forum, les paramètres de son compte, etc)
3. Copier l'URL
4. Se déconnecter
5. Coller l'URL. On est redirigé vers la page de connexion, avec le paramètre next bien positionné.
6. Se connecter
7. On est redirigé vers l'accueil au lieu de l'URL collée initialement.

J'arrive à causer le bug avec l'URL http://127.0.0.1:8000/membres/parametres/profil/.

Il faudrait aussi trouver pourquoi les tests ne montrent pas le problème...

[Arnaud-D]

C'est un bug intéressant. Les tests que j'avais écrits interrogeaient directement la vue en POST, en envoyant correctement le paramètre next dans l'URL. Sauf que quand on GET la page, l'attribut action du formulaire n'était pas correct : le next n'y était pas. Quand on soumet le formulaire comme un humain, l'info n'était alors pas envoyée et on retombait sur la redirection par défaut, la page d'accueil. J'ai ajouté un test qui regarde si on a bien un action={next} dans la page.

C'est le genre de choses qui bénéficieraient de tests plus englobants, par exemple avec selenium.

[philippemilink]

QA OK ✔️