gestioCOF/kfet/middleware.py

# -*- coding: utf-8 -*-

from kfet.backends import KFetBackend


def kfet_auth_middleware(get_response):
    kfet_backend = KFetBackend()

    def middleware(request):
        temp_request_user = kfet_backend.authenticate(request)
        if temp_request_user:
            request.real_user = request.user
            request.user = temp_request_user
        return get_response(request)

    return middleware
Py2 compatible 2016-09-01 00:45:44 +02:00			`# -- coding: utf-8 --`

Authentification K-Psul 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. 2016-08-19 06:20:37 +02:00			`from kfet.backends import KFetBackend`

Django1.11-style MiddleWares The design of middlewares has changed in Django 1.11 2017-02-23 00:43:23 +01:00
			`def kfet_auth_middleware(get_response):`
			`kfet_backend = KFetBackend()`

			`def middleware(request):`
Authentification K-Psul 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. 2016-08-19 06:20:37 +02:00			`temp_request_user = kfet_backend.authenticate(request)`
			`if temp_request_user:`
Auth spéciale - 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 2016-08-20 23:31:30 +02:00			`request.real_user = request.user`
Authentification K-Psul 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. 2016-08-19 06:20:37 +02:00			`request.user = temp_request_user`
Django1.11-style MiddleWares The design of middlewares has changed in Django 1.11 2017-02-23 00:43:23 +01:00			`return get_response(request)`

			`return middleware`