Authentification CAS SSO

Bonjour,
Il s'agit en effet de la page par défaut (page avec le lien "Authentification" et le lien "Se connecter localement")
Merci de votre aide.

Et bien sûr pas les + dans les cases du planning pour réserver ?
Pour essayer d'approfondir : vous êtes authentifié par un serveur CAS ou directement par interrogation de l'annuaire LDAP ?

Bonjour,
=> Oui, il n'y a pas des + dans les cases du planning pour réserver.
=> En effet, on s'authentifie par un serveur CAS qui retourne l'attribut "mail" si l'on est "reconnu par le serveur" puis il y a interrogation de l'annuaire LDAP pour récupérer les informations de l'utilisateur authentifié avec l'attribut "mail" précédent. Si les informations sont retournées par l'annuaire, il y a "il me semble" création d'une session et insertion des infos dans la BDD si elles n'existent pas déjà. Le problème c'est que une fois authentifié on est redirigé vers la page d'accueil par défaut. Il me semble que ce cas d'authentification n'est pas traité ?
Je vous remercie de votre aide

Bonjour,
un cas similaire semble avoir été traité dans la branche 3.5.1.
Pourriez-vous tester si les fichiers  github.com/JeromeDevome/GRR/tree/GRR-3.5.1  permettent l'authentification par SSO et LDAP ?
Cordialement,
YN

Bonjour Yan,
Je suis désolé de vous répondre tardivement, j'ai été en congé.
Les nouveaux fichiers que j'ai installé ont permis de résoudre le problème. En effet, je suis redirigé vers la bonne page, et j'ai les + me permettant de faire des réservations. Une réservation a été créer avec succès.
Je vous remercie de votre aide.

Bonjour,
Je reviens à ce sujet, car, j'ai rencontré un problème lorsqu'un utilisateur souhaitait s'authentifier. Voilà le message d'erreur reçu :

"Un probleme est survenu lors de la création d'un nouvel utilisateur!
Veuillez contacter le support technique. Incorrect string value:'xEBI' for column 'grr':'grr_utilisateurs'.'prenom' at row 1"

Je vous remercie.
(Je ne sais pas s'il fallait réactiver le sujet et ou ?)

Bonjour,
Je reviens à ce sujet qui était résolu, mais dont j'ai eu récemment un message d'erreur lorsqu'un utilisateur souhait s'authentifier. En effet, voilà le message d'erreur :
Un probleme est survenu lors de la création d'un nouvel utilisateur!
Veuillez contacter le support technique. Incorrect string value:'\xEBI' for column 'grr'.'grr_utilisateurs'.'prenom' at row 1
Je crois que le problème survient lorsque le prénom possède un accent, si non, il n'y a pas de problème lors d'une autre authentification.
Par ailleurs, voilà l'information sur Interclassement pour les colonnes de type varchar  dans la base de données est : utf8mb4_unicode_ci et utf8mb4_general_ci  Est-ce qu'il y a lieu de changer cet interclassement dans la base de données ? Si oui, que doit-on utiliser ?
Faut-il utiliser uniquement utf8mb4_unicode_ci  ?
Ou bien faut-il gérer cela avant l'insertion en base ? Si oui, comment ?

J'ai reçu d'un utilisateur en télétravail qu'il n'arrive pas à s'authentifier(il utilise un VPN avec une carte d'accès), est-ce que cela est lié à l'application ou au serveur SSO CAS ?
Voilà le message reçu en pièce jointe.


Je vous remercie beaucoup d'avance.

Bonjour,
il semble qu’il y ait un codage de trop
Je reprends le code dès que possible.
Cordialement
YN

Bonjour,
en revenant sur votre message, je pense qu'il faut s'assurer que tous les codages de votre serveur de DB sont cohérents. À savoir utf8mb4 pour les codages et utf8mb4_unicode_ci pour les interclassements. Cela devrait aussi marcher avec utf8_general_ci mais il ne faut pas mélanger les deux.
Cordialement,
YN

Bonjour,
Je vous remercie de votre réponse.
J'ai essayé de mettre en cohérence comme vous l'avez expliqué mais j'ai la même réponse
"Un probleme est survenu lors de la création d'un nouvel utilisateur!
Veuillez contacter le support technique. Incorrect string value:'\xE9rald' for column 'grr'.'grr_utilisateurs'.'prenom' at row 1"
En effet j'ai essayé avec :
-uniquement utf8mb4_unicode_ci pour les interclassements => message d'erreur
-uniquement utf8_general_ci pour les interclassements => message d'erreur
Je ne sais pas comment savoir si le codage est avec utf8mb4 ?
Par ailleurs, j'ai vu dans la ligne 240 à la ligne 246 du fichier includes/sessions.inc.php
un code qui converti depuis UTF-8 les jeux de caractère par défaut , je ne sais pas si cela peut se passer par là ?

Bonjour,
un part du problème vient du fait que MySQL définit un type utf8 qui n'est pas standard, codé sur 3 octets.
Il faut passer en utf8mb4 (4 octets) pour être dans l'UTF-8 standard. Les interclassements utf8mb4_unicode_ci et utf8mb4_general_ci ne sont pas exactement les mêmes mais font grosso modo le même travail.
Maintenant (GRR 3.5.x+) que la base est entièrement en utf8mb4, il ne faut pas convertir l'UTF-8 rendu par LDAP en ISO. Voyez si votre réglage le fait ou pas.
Pouvez-vous confirmer que le problème se produit pour un utilisateur dont le prénom a un accent ou un autre caractère "accentué" ?
Cordialement,
YN