Development #43585
Accès aux attributs LDAP suite à une reconnexion en tant qu'un autre utilisateur
0%
Description
Suite aux dernières évolutions de la fonctionnalité de reconnexion en tant qu'un autre utilisateur, les attributs issus de l'annuaire LDAP ne sont plus propagés aux services auxquels l'utilisateur tente d'accéder. Seuls les attributs stockés dans Authentic sont accessibles (identifiant & courriel par exemple).
Cette régression est assez gênante, car il est assez courant de mettre en place un filtrage d'accès par exemple sur une valeur issue d'un attribut LDAP et dans ce cas précis, l'utilisateur se voit interdire l'accès. La fonctionnalité de reconnexion en tant qu'un autre utilisateur perd donc beaucoup de son intérêt avec cette contrainte.
Serait-il envisageable de corriger cela ?
Exemple pour reproduire ce problème:- configurer un service (via SAML par exemple) avec un attribut issu de l'annuaire
- se connecter avec un utilisateur admin
- dans l'interface /manages/users/XXX, se reconnecter avec un autre utilisateur
- tenter d'accéder au service configuré initialement
L'attribut SAML ne sera alors pas renseigné bien qu'existant dans l'annuaire LDAP.
Fichiers
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
Ça n'a jamais marché comme cela avant, les attributs LDAP ont toujours été indisponible; c'était un effet de bord qui faisait que si l'utilisateur précédent venait du backend LDAP le suivant aussi (mais a priori en sens inverse ça devait bugger) :
-def su(request, username, redirect_url='/'):
- '''To use this view add:
-
- url(r'^su/(?P<username>.*)/$', 'authentic2.views.su', {'redirect_url': '/'}),
- '''
- if request.user.is_superuser or request.session.get('has_superuser_power'):
- su_user = shortcuts.get_object_or_404(User, username=username)
- if su_user.is_active:
- request.session[SESSION_KEY] = su_user.id
- request.session['has_superuser_power'] = True
- return http.HttpResponseRedirect(redirect_url)
- else:
- return http.HttpResponseRedirect('/')
Je faisais des manipulations limites en session, mais je ne changeais pas le backend, il faudrait traiter cela de façon particulière, à la manière du backend LDAPBackendPasswordLost.
Mis à jour par Loïc Dachary il y a environ 3 ans
Pour archive, bien que LDAPBackendPasswordLost fonctionne comme attendu les attributs ne sont pas disponibles, mais pour une autre raison
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Fichier 0001-views-use-LDAPBackendPasswordLost-to-switch-to-LDAP-.patch 0001-views-use-LDAPBackendPasswordLost-to-switch-to-LDAP-.patch ajouté
- Tracker changé de Bug à Development
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Au dessus de #52638 pour avoir un simulate_authentication() qui respecte le user.backend déjà présent.
Mis à jour par Loïc Dachary il y a environ 3 ans
- Fichier 0001-views-use-LDAPBackendPasswordLost-to-switch-to-LDAP-.patch 0001-views-use-LDAPBackendPasswordLost-to-switch-to-LDAP-.patch ajouté
Après rebase sur main (#52638 a été merge) j'ai pu vérifier que le test passe.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Statut changé de Solution proposée à Résolu (à déployer)
commit c70f205987e6660edeb4a6dbed06bf19b6905b9b
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Thu Apr 1 17:36:54 2021 +0200
views: use LDAPBackendPasswordLost to switch to LDAP account (#43585)Mis à jour par Frédéric Péters il y a presque 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
views: use LDAPBackendPasswordLost to switch to LDAP account (#43585)