> bonjour, > > en tripatouillant un peu dans le code, j'ai fait face à un problème > assez étrange. > en essayant de me loguer avec l'user glpi (super-admin), je me > retrouvais systématiquement loggué en temps que post-only. > cependant, mes logs de query sql étaient pourtant bon, et envoyaient > bien les infos correctes. > avec un petit print_r($identificat->user->fields); (ce qui est utilisé > dans la page de login), je me suis rendu compte que mon user avait 2 > types. > le premier est le type post-only, créé par défaut quand on faire $user > = new User; (c'est une variable de la classe user, initialisée à la > valeur post-only par défaut). > le second est le type correct, à savoir super-admin pour glpi. > la différence entre les deux est la casse. > à savoir que le type par défaut s'écrit type, et que le type récupéré > dansla base de donnée s'écrit TYPE. >
J'ai regardé un peu le code ce midi voila mes constatations : Effectivement si l'on décompose un login dans le temps on se rendra compte que lors d'une tentative réussie la variable $identificat->user->fields["type"] passe par deux états successifs : - Le premier est systématiquement "post-only" (au moment de l'initialisation de l'objet user) - Le second sera le type correspondant à l'utilisateur que l'on vient de logguer qui est récupéré dans la base de données. Chez moi pour ces deux cas le nom du champ type est bien en minuscule et la valeur de ce champs aussi, il n'existe pas de champs $identificat->user->fields["TYPE"]. Donc je n'ai pas constaté de probleme de casse à ce niveau la, vous est il possible de nous en dire un peu plus, quelle procédure de login est utilisée ? Avez vous modifié la base de données ? etc etc. > Il est quasi sur que ce bug est du à la couche AdoDB que j'utilise > pour mon portage vers PostGreSQL, cependant ca me semble risqué de ne > pas vérifier ce qu'on recoit dans les query sql du type select... > La dessus j'ai peur de ne pas comprendre ce que vous entendez par "risqué" et par "verifier ce qu'on recoit dans les query sql de type select"... Nous sommes preneurs de toute remarque pouvant faire avancer le projet donc n'hésitez pas à nous en dire plus. > (bien sur, comme le portage vers un autre dbms n'est pas à votre ordre > du jour, je comprendrai que vous ignoriez ce petit problème qui > n'empeche absolument pas glpi de fonctionner tout seul sans accroc > quand il est utilisé avec son sgbd préféré) A ce sujet un thread dans lequel nous avons pris le temps de justifier notre position est ouvert sur cette mailing liste. Si vous l'avez lu vous aurez retenu que nous ne sommes pas contre un portage vers un autre SGBD s'il apporte une plus-value au projet autre que celle de tourner sur un SGBD de plus. Ceci étant dit le thread est encore ouvert, pour éviter de mélanger les sujets, merci à l'avenir de poster vos remarques constructives dans celui-ci. -- Bazile
