Bonjour Mickaël et Mathieu,
Merci pour vos réponses et pistes, et désolé de ma réponse (aussi) tardive.
Je dois avouer que je n'ai pas la main sur tous les éléments du réseau, mais uniquement aux serveurs Moodle (sur lesquels j'ai par contre tous les droits). J'ai bien impliqué les services informatiques, mais ils n'ont pas trouvé ce qui bloque (pour le moment). A priori tout est OK du côté des certificats, et les différents serveurs sont synchronisés sur des serveurs de temps.
Sans être un spécialiste, je ne vois pas pourquoi le Cross-Origin aurait une telle influence.
Le problème n'est pas lié à une vieille page laissée en suspens : il se produit lorsqu'on suit toute la procédure de connexion (avec authentification CAS intermédiaire) ou lors de la connexion à Moodle (étant déjà authentifié dans l'ENT).
J'ai essayé de regarder le code Moodle : il n'y a manifestement pas eu de modification de code dans la version 3.5 (toujours utilisée sur certaines instances) sur ce qui est lié à l'authentification ou à la connexion depuis le 10 mai 2019. Et depuis, seuls des correctifs de sécurités sont apportés dans cette branche 3.5. Alors à moins qu'un changement caché dans les librairies en soit la cause, je doute que Moodle soit en cause (mais j'envisage toutes les possibilités). A minima pas de changement récent dans authlib.php.
Concernant les fichiers de log, je ne trouve rien dans /var/log/httpd/ssl_error_log lié à mes problèmes.
Par contre, je trouve bien des éléments dans /var/log/httpd/error_log liés aux problèmes de connexion (même heure exacte), et impliquant AH00052, le plus souvent avec "child pid xxxx exit signal Aborted", mais parfois avec d'autres éléments ("child pid xxxx exit signal Segmentation fault", "child pid xxxx exit signal Illegal instruction"...). Des recherches sur l'erreur AH00052 ne m'ont pas permis de trouver d'explication claire (mes virtualhosts sont bien déclarés sur une adresse IP). Par ailleurs, (il me semble qu') on a parfois ces lignes qui apparaissent dans les log d'erreur, alors même que la connexion a fonctionné.
Ayant eu une piste soufflée concernant CAS, j'ai vérifié que Moodle utilise bien la librairie CAS qu'il intègre via le fichier auth/cas/CAS/CAS.php (et le dossier auth/cas/CAS/CAS) plutôt que celle fournie par PHP. On peut voir la version en cherchant PHPCAS_VERSION (dans CAS.php) ; et j'ai constaté que celle de Moodle n'était pas la plus à jour.
Dans mes prochains tests, j'ai donc remplacé ces éléments d'origine de Moodle (dossier CAS et fichier CAS.php) par les versions issues de PHP 7.1.32 ; on verra si ça change quelque chose.
Afin d'être plus efficace (et éviter de tester 36 fois manuellement), et lever les ambiguïtés, j'aurais besoin de pouvoir automatiser ces opérations de connexion sur mes plateformes, que ce soit via un compte CAS ou un compte manuel, en étant capable de garder trace des résultats obtenus, afin d'être certain des cas qui génèrent les problèmes (et ceux qui n'en génèrent pas).
On m'a parlé de JMeter qui permettrait (peut-être) cela. Je dois avouer que je ne connais pas du tout cet outil, et que j'ai peur de passer pas mal de temps dessus avant d'arriver à en tirer quelque chose (site en https + CAS).
Concernant la console du navigateur, certaines fois il n'y a presque rien (hormis l'image du message d'erreur) et d'autres fois, on constate que les éléments semblent s'appeler plusieurs fois, et en boucle (ainsi que les différents entêtes). On retrouve dans error_log le même nombre de lignes que d'occurrences des entêtes (et de leur répétition).
S'il y a 3 lignes d'erreur, on retrouve 3 fois le listage des entêtes, la première fois avec pour chaque élément d'entête une occurrence des données, la deuxième fois avec pour chaque élément d'entête deux occurrences des données, la troisième fois avec pour chaque élément d'entête trois occurrences des données...
Je reste toujours intéressé par des pistes, idées, outils.
Séverin
Merci pour vos réponses et pistes, et désolé de ma réponse (aussi) tardive.
Je dois avouer que je n'ai pas la main sur tous les éléments du réseau, mais uniquement aux serveurs Moodle (sur lesquels j'ai par contre tous les droits). J'ai bien impliqué les services informatiques, mais ils n'ont pas trouvé ce qui bloque (pour le moment). A priori tout est OK du côté des certificats, et les différents serveurs sont synchronisés sur des serveurs de temps.
Sans être un spécialiste, je ne vois pas pourquoi le Cross-Origin aurait une telle influence.
Le problème n'est pas lié à une vieille page laissée en suspens : il se produit lorsqu'on suit toute la procédure de connexion (avec authentification CAS intermédiaire) ou lors de la connexion à Moodle (étant déjà authentifié dans l'ENT).
J'ai essayé de regarder le code Moodle : il n'y a manifestement pas eu de modification de code dans la version 3.5 (toujours utilisée sur certaines instances) sur ce qui est lié à l'authentification ou à la connexion depuis le 10 mai 2019. Et depuis, seuls des correctifs de sécurités sont apportés dans cette branche 3.5. Alors à moins qu'un changement caché dans les librairies en soit la cause, je doute que Moodle soit en cause (mais j'envisage toutes les possibilités). A minima pas de changement récent dans authlib.php.
Concernant les fichiers de log, je ne trouve rien dans /var/log/httpd/ssl_error_log lié à mes problèmes.
Par contre, je trouve bien des éléments dans /var/log/httpd/error_log liés aux problèmes de connexion (même heure exacte), et impliquant AH00052, le plus souvent avec "child pid xxxx exit signal Aborted", mais parfois avec d'autres éléments ("child pid xxxx exit signal Segmentation fault", "child pid xxxx exit signal Illegal instruction"...). Des recherches sur l'erreur AH00052 ne m'ont pas permis de trouver d'explication claire (mes virtualhosts sont bien déclarés sur une adresse IP). Par ailleurs, (il me semble qu') on a parfois ces lignes qui apparaissent dans les log d'erreur, alors même que la connexion a fonctionné.
Ayant eu une piste soufflée concernant CAS, j'ai vérifié que Moodle utilise bien la librairie CAS qu'il intègre via le fichier auth/cas/CAS/CAS.php (et le dossier auth/cas/CAS/CAS) plutôt que celle fournie par PHP. On peut voir la version en cherchant PHPCAS_VERSION (dans CAS.php) ; et j'ai constaté que celle de Moodle n'était pas la plus à jour.
Dans mes prochains tests, j'ai donc remplacé ces éléments d'origine de Moodle (dossier CAS et fichier CAS.php) par les versions issues de PHP 7.1.32 ; on verra si ça change quelque chose.
Afin d'être plus efficace (et éviter de tester 36 fois manuellement), et lever les ambiguïtés, j'aurais besoin de pouvoir automatiser ces opérations de connexion sur mes plateformes, que ce soit via un compte CAS ou un compte manuel, en étant capable de garder trace des résultats obtenus, afin d'être certain des cas qui génèrent les problèmes (et ceux qui n'en génèrent pas).
On m'a parlé de JMeter qui permettrait (peut-être) cela. Je dois avouer que je ne connais pas du tout cet outil, et que j'ai peur de passer pas mal de temps dessus avant d'arriver à en tirer quelque chose (site en https + CAS).
Concernant la console du navigateur, certaines fois il n'y a presque rien (hormis l'image du message d'erreur) et d'autres fois, on constate que les éléments semblent s'appeler plusieurs fois, et en boucle (ainsi que les différents entêtes). On retrouve dans error_log le même nombre de lignes que d'occurrences des entêtes (et de leur répétition).
S'il y a 3 lignes d'erreur, on retrouve 3 fois le listage des entêtes, la première fois avec pour chaque élément d'entête une occurrence des données, la deuxième fois avec pour chaque élément d'entête deux occurrences des données, la troisième fois avec pour chaque élément d'entête trois occurrences des données...
Je reste toujours intéressé par des pistes, idées, outils.
Séverin