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".
Related issues
Associated revisions
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)
History
#1 Updated by Christophe Deseure over 11 years ago
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 Updated by Joël Cuissinat over 11 years ago
- Target version set to Envole 2.5.1 RC
- Distribution set to Toutes
#3 Updated by Gérald Schwartzmann over 11 years ago
- Assigned To set to Gérald Schwartzmann
- % Done changed from 0 to 30
#4 Updated by Gérald Schwartzmann over 11 years ago
- Status changed from Nouveau to Résolu
- % Done changed from 30 to 100
Appliqué par commit 46b4ffba4381f552c09ef9aa8d224af4762d775d.
#5 Updated by Gérald Schwartzmann over 11 years ago
Appliqué par commit 622cf084b5edbdded2d5d7de0a067f350f5369ae.
#6 Updated by Gérald Schwartzmann over 11 years ago
Appliqué par commit 0fba7788a8364bc2e9ea78ec16b8284d439ffb15.
#7 Updated by Gérald Schwartzmann over 11 years ago
- Status changed from Résolu to Fermé
#8 Updated by Arnaud FORNEROT about 10 years ago
- Status changed from Fermé to À valider
- Assigned To changed from Gérald Schwartzmann to Lionel Morin
- Target version changed from Envole 2.5.1 RC to Envole 3.3.3
- Distribution changed from Toutes to 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 Updated by Arnaud FORNEROT about 10 years ago
- % Done changed from 100 to 0
#10 Updated by Christophe Deseure about 10 years ago
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 Updated by Christophe Deseure about 10 years ago
- File demande2019.patch View added
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 Updated by Arnaud FORNEROT about 10 years ago
- Target version changed from Envole 3.3.3 to Envole 3.3.4
#13 Updated by Arnaud FORNEROT about 10 years ago
- Target version changed from Envole 3.3.4 to Envole 3.3.5
#14 Updated by Arnaud FORNEROT almost 10 years ago
- Target version deleted (
Envole 3.3.5)
#15 Updated by Arnaud FORNEROT over 8 years ago
- Status changed from À valider to Résolu
- % Done changed from 0 to 100
- Distribution changed from EOLE 2.3 to EOLE 2.4
ajaxplorer n'est plus maintenu
c'est pydio qui le remplace
et le problème est résolu sur pydio
#16 Updated by Arnaud FORNEROT almost 8 years ago
- Status changed from Résolu to Fermé
- Target version set to Envole 4.0 RC