Configuration SSO CAS problème d'intégration d'un SSO local dans la version 4.2.4

[LOUBS31]

Bonjour à tous,

Notre petite entreprise a son propre SSO local.
Dans la version de GRR 3.4.0, nous avions réussi à intégrer notre SSO pour simuler les variables d'un SSO type CAS.

Pour se faire, nous avions remplacer l'intégralité du contenu du fichier include/cas.inc.php par les variables de notre SSO.

uid; $user_nom = SSOPerso::user()->sn; $user_prenom = SSOPerso::user()->givenName; $user_mail = SSOPerso::user()->mail; Et nous avions configuré l'application dans l'administration Configuration SSO > Prise en compte d'un environnement CAS (SSO) > Usager. Ainsi tous les utilisateurs authentifiés avaient le profil d'usager. Tout fonctionne correctement. -------- Voyant la nouvelle version GRR 4.2.4 très attrayante et compatible php 8.1, nous avons essayé de reproduire la même chose. Là, oh surprise quelques petits changements dans la structure. Un dossier personnalisation est apparu et d'autres fichiers liés. En reprenant, la même technique que la version précédente, les utilisateurs arrivent à se créer dans la table utilisateurs mais une page blanche apparait après l'authentification. Seul les utilisateurs avec un profil "administrateur" arrivent à utiliser l'application. Les profils "Visiteur", "Usager" et "Gestionnaire des utilisateurs" ont tous une page blanche après l'authentification. Bien sûr, pas d'erreur dans /var/log/apache2/error.log qui pourrait m'indiquer le problème. Avez-vous une idée pour faciliter l'intégration de notre SSO et quel fichier dois-je modifier ? Merci à tous de votre contribution. ;)

[JeromeDevome]

Bonjour,
Avez-vous essayez un autre navigateur ? Certains navigateur sont plus bavard que d'autre sur les erreurs.
Quand vous regarder le code source de la page vous voyez quelques choses ?

[ynaessens]

Bonjour,
si vous aviez la possibilité de tester l'installation avec la release 3.5.1c de GRR, cela permettrait de savoir si c'est l'intégration de CAS à GRR qui est en cause. Les versions de CAS utilisées sont en effet différentes entre les versions 3.5.1 et 4.2+.
S'il n'y a pas de différence entre les deux, on cherchera à rendre CAS plus bavard.
Cordialement,
YN

[LOUBS31]

Bonjour,
J'ai installé la version 3.5.1c et la version 4.2.4 sur un serveur Ubuntu 20.04
Version PHP : 7.4.3-4ubuntu2.19
Base de données : : mysql => 5.5.5-10.3.38-MariaDB-0ubuntu0.20.04.1
En modifiant le "cas.inc.php" comme indiqué avec la version 3.4.0 ---> TOUT EST OK

Du coup, j'ai installé la version 3.5.1c et la version 4.2.4 sur un serveur Ubuntu 22.04
Version PHP : 8.1.2-1ubuntu2.14
Base de donnée : mysql 5.5.5-10.6.12-MariaDB-0ubuntu0.22.04.1
En modifiant le "cas.inc.php" comme indiqué avec la version 3.4.0 ---> Page blanche sauf pour les administrateurs Ext ou Local

Les deux serveurs ont les mêmes modules php, hormis la version php et MariaDB qui diffèrent !!

Du coup, je suis preneur d'un débogueur ou d'un logigramme de l'appli pour trouver l'erreur sous php 8.1.2 ?

Merci de votre aide.
Bonne journée

[ynaessens]

Rassurez-moi : un utilisateur local sans droits particuliers peut se connecter ?

[LOUBS31]

Oui oui, un utilisateur local avec des droits "Visiteur" par exemple peut se connecter.

[ynaessens]

Bien !
On a donc un problème CAS avec php8.

[LOUBS31]

Bonjour,
Version 4.2.4 : Petit problème lors de la mise à jour des tables.
Lors de la mise à jour de la base de données, passant de version 3.4.0 à 4.2.4, tous les rendez-vous agendés ont décalé de plus 6 heures.
Exemple : le rdv du 8 février de 9H à 11H est devenu un rdv du 8 février de 15H à 17H.

Ceci pour tous les rendez-vous.

Avez vous une idée avant que je regarde ?

Bonne journée,

[LOUBS31]

Problème corrigé en faisant une boucle SQL pour changer les valeurs des champs "start_time" & "end_time" dans la table "grr_entry".
Extraire la valeur enregistrée et retrancher 21600 correspand aux 6 heures.

[ynaessens]

Bonjour,
ce que vous décrivez ne m'est jamais arrivé lors d'une montée de version.
Le serveur est-il dans le même fuseau horaire que les postes des clients ?
Avez-vous vérifié qu'il n'y avait pas un décalage horaire antérieurement par paramétrage dans le fichier config.inc.php ?
Cordialement,
YN

[anteldan]

Bonjour,

ça m'évoque une prise en compte de la date au format GMT. Les dates auparavant étaient "brutes" et maintenant elles se baseraient sur un réglage de fuseau horaire (?). C'est ma seule intuition.

Cordialement,

Daniel

[LOUBS31]

Ha ha ... possible !

[JeromeDevome]

Bonjour @LOUBS31 , je pense au fuseau horaire dans le fichier config.inc.perso . Je présume que vous êtes un Canadien et que votre votre ancien fichier config vous avez mis date_default_timezone_set('America/Montreal');

[LOUBS31]

Bonjour,
Non, je suis positionné à Bordeaux ... Et oui, on ne choisit pas !
Notre société a un serveur temps pour l'ensemble du parc.
GRR_3.4.0 : include/config.inc.php --> date_default_timezone_set('Europe/Paris');
GRR_4.2.4 : include/config.inc.php --> date_default_timezone_set('Europe/Paris'); --> Donc même config dans les deux

"Les dates auparavant étaient "brutes" --> Du coup si c'est le cas, ceci peut expliquer.

Je vais me pencher sur la version php8 pour l'authentication CAS, il doit y avoir une version d'un fichier à déprécier.

Merci pour votre aide. ;)

[ynaessens]

Bonjour,
ce décalage horaire me laisse perplexe, surtout si votre hébergement n'a pas changé.
Pour ce qui est de l'authentification CAS, GRR 4.2.4 embarque bien phpCAS 1.6.1 qui est censé fonctionner avec php 8. Vous confirmez qu'un profil administrateur reçoit son authentification CAS, mais pas un simple utilisateur ?
Cordialement,
YN

[LOUBS31]

Limite, le problème de décalage d'horaire est bénin et vite corrigé.

Concernant le SSO CAS :
Oui, un utilisateur EXT avec des droits "administrateur" accède sans problème à l'application comme les utilisateurs locaux.

Pour rappel, nous supprimons l'intégralité du contenu du fichier include/cas.inc.php en reprenant les variables : $user_nom, $user_prenom, $user_mail avec nos valeurs

Dans l'administration, nous choisissons Configuration SSO > Prise en compte d'un environnement CAS (SSO) > Usager.

Sur un serveur en php 7, tout est fonctionne normalement.
Sur un serveur en php 8, une page blanche apparait après notre authentification. Toutes les variables sont bien récupérées.
L'utilisateur EXT ne s'inscrit pas dans la table utilisateur.

[ynaessens]

Vous avez modifié ./include/cas.inc.php ou ./personnalisation/config_CAS.inc.php ?