Anomalie #2019
changement d'utilisateur problématique depuis le portail car session persistante
Description
Si on se connecte sur le portail et qu'on accède à ajaxplorer, on a tendance à se déconnecter du portail et non directement depuis le lien de déconnexion de Ajaxplorer.
Dans ce cas, la session de Ajaxplorer est conservée et l'utilisateur suivant se voit refuser l'accès avec le message :
"Cannot login to FTP server with user toto" où toto est le précédent utilisateur ayant accédé à l'application
Il y a pourtant un principe de déconnexion globale qui ne semble pas fonctionner pour ajaxplorer.
Une solution possible et de faire un "unset($_SESSION);" après le "session_start()" présent dans "index.php".
l'absence de "$_SESSION["AJXP_USER"]" permet alors à "AuthService::preLogUser" de repasser par le client CAS
et l'absence de "$_SESSION["phpCAS"]" force le client CAS à réinterroger le serveur CAS
Comme la page d'index semble n'être appelée que la première fois, toute l'utilisation se faisant ensuite en AJAX, cela peut donc peut-être convenir comme principe de refaire toute l'authentification à chaque accès à "index.php".
Demandes liées
Révisions associées
ajout de deux unset pour obliger le rechargement des pages fixes #2019
dans la page index.php ajout de deux unset
ajout de deux unset pour obliger le rechargement des pages fixes #2019
dans la page index.php ajout de deux unset
ajout de deux unset pour obliger le rechargement des pages fixes #2019
dans la page index.php ajout de deux unset
Correction de la déconnexion (ref #2019)
- Application de l'ancien patch
- Modification de la CASsification
Ajout du patch 2019 et correction de la CASsification (ref #2019)
Suppression du patch non appliqué (ref #2019)
Rétablissement d'un patch qui avait été supprimé (refs #2019)
Historique
#1 Mis à jour par Christophe Deseure il y a plus de 12 ans
Après test sur un établissement, le "unset($_SESSION)" semble trop radical car l'application nous présente un formulaire de connexion et devient inutilisable.
Par contre la suppression des 2 seules variables de session "AJXP_USER" et "phpCAS" fonctionne correctement.
#2 Mis à jour par Joël Cuissinat il y a plus de 12 ans
- Version cible mis à Envole 2.5.1 RC
- Distribution mis à Toutes
#3 Mis à jour par Gérald Schwartzmann il y a plus de 12 ans
- Assigné à mis à Gérald Schwartzmann
- % réalisé changé de 0 à 30
#4 Mis à jour par Gérald Schwartzmann il y a plus de 12 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 30 à 100
Appliqué par commit 46b4ffba4381f552c09ef9aa8d224af4762d775d.
#5 Mis à jour par Gérald Schwartzmann il y a plus de 12 ans
Appliqué par commit 622cf084b5edbdded2d5d7de0a067f350f5369ae.
#6 Mis à jour par Gérald Schwartzmann il y a plus de 12 ans
Appliqué par commit 0fba7788a8364bc2e9ea78ec16b8284d439ffb15.
#7 Mis à jour par Gérald Schwartzmann il y a environ 12 ans
- Statut changé de Résolu à Fermé
#8 Mis à jour par Arnaud FORNEROT il y a environ 11 ans
- Statut changé de Fermé à À valider
- Assigné à changé de Gérald Schwartzmann à Lionel Morin
- Version cible changé de Envole 2.5.1 RC à Envole 3.3.3
- Distribution changé de Toutes à EOLE 2.3
Réouverte le problème est de nouveau présent
Voir du coté de la nouvelle librairie CAS
Au besoin doublé le signalement pour résoudre en 2.2
#9 Mis à jour par Arnaud FORNEROT il y a environ 11 ans
- % réalisé changé de 100 à 0
#10 Mis à jour par Christophe Deseure il y a environ 11 ans
Je parle dans les lignes qui suivent du problème sur scribe 2.2.
Ne connaissant pas l'architecture d'ajaxplorer, c'est la seule solution que j'ai pu proposer à l'époque mais il y a peut-être plus propre.
A confirmer mais je ne vois pas la modification du index.php faite par Gérald dans mon ajaxplorer de tests, le patch s'applique-t-il vraiment ?
Il est donc possible que ce problème de déconnexion persiste toujours.
A Créteil, le index.php est écrasé par notre personnalisation académique depuis ce souci donc nous avons bien les "unset" qui force la réinterrogation du serveur CAS et corrigeait donc le problème de déconnexion incomplète.
Depuis la mise à jour du mardi 19 mars 2013, ce correctif provoque une boucle de redirection et rend ajaxplorer inutilisable.
Il semble que cela vienne d'un changement de comportement du client CAS.
- en appelant "/ajaxplorer", les 2 "unset" force la réinterrogation systématique du serveur CAS afin d'éviter d'arriver connecté sous le compte du précédent utilisateur
- après redirections, on revient sur une uri du type "/ajaxplorer?ticket=..."
- avant, on restait sur cette url et on était donc sur ajaxplorer avec le ticket qui restait affiché mais sans savoir pourquoi, maintenant on est redirigé vers "/ajaxplorer" ce qui doit être la cause de la boucle puisqu'on repart au point 1
#11 Mis à jour par Christophe Deseure il y a environ 11 ans
- Fichier demande2019.patch Voir ajouté
Mon test est concluant, la déconnexion du serveur CAS entraîne bien une demande de reconnexion lors de l'accès suivant à "/ajaxplorer".
Par contre, le patch est fort verbeux indiquant des différences où il n'y en a pas du fait du remplacement de toutes les tabulations par des espaces.
Pour qu'il soit aisé de comprendre l'action du patch en regardant son contenu, j'en propose un plus light.
Cordialement.
#12 Mis à jour par Arnaud FORNEROT il y a environ 11 ans
- Version cible changé de Envole 3.3.3 à Envole 3.3.4
#13 Mis à jour par Arnaud FORNEROT il y a presque 11 ans
- Version cible changé de Envole 3.3.4 à Envole 3.3.5
#14 Mis à jour par Arnaud FORNEROT il y a presque 11 ans
- Version cible
Envole 3.3.5supprimé
#15 Mis à jour par Arnaud FORNEROT il y a environ 9 ans
- Statut changé de À valider à Résolu
- % réalisé changé de 0 à 100
- Distribution changé de EOLE 2.3 à EOLE 2.4
ajaxplorer n'est plus maintenu
c'est pydio qui le remplace
et le problème est résolu sur pydio
#16 Mis à jour par Arnaud FORNEROT il y a presque 9 ans
- Statut changé de Résolu à Fermé
- Version cible mis à Envole 4.0 RC