Bonjour,
Merci pour votre réponse rapide.
Oui, la connexion LDAP SSO était active auparavant. Je tiens à préciser que nous sommes passés d'une version 1.9.7 à une version 3.4.0.
Finalement, nous avons réussi à résoudre notre pb.
Il s'agissait de la "Restriction des connexions via l'iP" qui bizarrement était renseigné "NON" alors qu'il attendait une valeur numérique, voire vide dans notre cas puisque nous ne faisons pas de filtrage IP (peut être un problème lié à la migration ??)
A côté de ça, nous avons repéré un autre bug :
Lorsque nous faisons une connexion SSO et que l'utilisateur est déjà existant, il semblerait que GRR n'arrive pas à récupérer le nom/prénom de l'utilisateur et écrase ceux déjà enregistrés avec un message d'erreur. Lorsqu'il s'agit d'un nouvel utilisateur, il n'y a aucun problème, l'utilisateur est bien ajouté avec sa description complète.
Apache renvoie l'erreur suivante :
PHP Notice: Undefined variable: user_dn in /var/www/grr/include/session.inc.php on line 477, referer: https://......./grr/week_all.php?area=5&id_site=1
Nous avons donc contourné le problème en commentant la ligne qui fait la requête en cas d'utilisateur existant (ligne ~486):
/*if (grr_sql_command($sql2) < 0)
fatal_error(0, get_vocab("msg_login_created_error") . grr_sql_error());*/
J'ajouterais à ça, que nous avons un peu galéré lors de la migration à cause de problèmes d'accents et caractères spéciaux mal gérés. Certains étaient en ASCII, d'autres en HTML....
Voici une petite commande qui nous a permis de corriger l'essentiel. A appliquer directement sur le dump avant copie dans la nouvelle base.
cat dump.sql | awk '{gsub(/ /," ");gsub(/'/," ");gsub(/à/,"à");gsub(/è/,"è");gsub(/é/,"é");gsub(/%E9/,"é");gsub(/%E8/,"è");gsub(/%E0/,"à");gsub(/%EF/,"ï");gsub(/%3F/,"?");gsub(/%22/," ");gsub(/%2B/,"+");gsub(/%2F/," ");gsub(/%26/,"&");gsub(/%27/," ");gsub(/%20/," ");gsub(/%2C/," ");gsub(/%25/," ")}1' > dump_clean.sql
Auteur du sujet
