- Le backend d'auth K-Fêt est étendu pour aussi identifier une personne
dans le cas dans d'un formulaire en récupérant le password contenu
dans l'input de nom `KFETPASSWORD`
- Le middleware d'auth K-Fêt enregistre l'utilisateur connecté de
manière normale dans `request.real_user`
- Ajout d'un processeurs de contextes `kfet.context_processors.auth` qui
qui remplace `user` et `perms` par l'utilisateur connecté de manière
normale (`request.real_user`) et non celui connecté temporairement
- Modification de la vue de modif d'un compte pour s'adapter à l'auth
- Modification du template de modification d'un compte pour utiliser ce
moyen d'authentification
- Séparation du JS conservant le côté gauche d'une page à l'écran
- Séparation de l'encart gauche contenant les infos d'un comtpe dans un
autre template (`left_account`) pour l'utiliser dans `account_read` et `account_update`
- `base_nav` utilise user (qui est donc le vrai utilisateur connecté) au
lieu de `request.user` qui peut aussi bien être le vrai utilisateur
qu'un utilisateur temporaire
Si une (des) permission(s) sont nécessaires pour enregistrer/annuler des
opérations, une demande d'authentification apparaît où l'utilisateur
doit mettre le mot de passe d'un compte ayant la (les) permission(s)
requise(s).
Ce mot de passe est envoyé dans la requête AJAX via le header
`KFetPassword`.
Le middleware `KFetAuthenticationPassword` est appelée à chaque requête.
Il appelle lui même le backend `KFetBackend` qui est chargé de
retrouver le user dont le compte K-Fêt correspond au mot de passe défini
dans le header `KFETPASSWORD`.
Si le header n'est pas présent ou
qu'aucun utilisateur ne correspond à ce mot de passe, le middleware ne
fait... rien !
Dans le cas où un user est trouvé, il est "chargé" dans
`request.user` permettant ainsi de connecter l'utilisateur pour ce cycle
requête/réponse sans déconnecter l'utilisateur connecté de manière
normale.
Précédemment, GestioCOF utilisait django-cas, qui n'est plus maintenu.
Ceci le remplace par django-cas-ng, un fork plus récent et maintenu.
En particulier, django-cas-ng est compatible avec Python 3,
contrairement à django-cas.
Ce patch enlève la vérification faite par django-debug-toolbar pour ne
s'afficher que si l'IP source est dans l'option de configuration
INTERNAL_IPS. Ceci permet son fonctionnement avec Vagrant.
Fixes#8.
Ce patch enlève la vérification faite par django-debug-toolbar pour ne
s'afficher que si l'IP source est dans l'option de configuration
INTERNAL_IPS. Ceci permet son fonctionnement avec Vagrant.
Fixes#8.
Ce commit ajoute une configuration Vagrant permettant d'avoir un
environnement de développement facile à installer et réutilisable (cf
README.md).
En particulier :
- Vagrantfile est un fichier qui décrit une machine virtuelle Vagrant.
La configuration est assez proche des défauts, et n'introduit que
deux différences : les ports 8000 et 80 sont bindés sur les ports
8000 et 8080 (respectivement) sur la machine hôte, et le script
`provisioning/bootstrap.sh` est utilisé pour configurer une nouvelle
machine virtuelle.
- provisioning/bootstrap.sh est un script shell qui s'occupe
d'installer les paquets nécessaire et de configurer la machine
virtuelle pour que GestioCOF fonctionne.
- cof/settings_dev.py est un fichier de configuration minimal
permettant de faire fonctionner GestioCOF, configuré pour être
utilisé avec Vagrant mais facilement adaptable.
