Bonjour,
je rencontre un soucis une fois que dolibarr est installé. Lorsque que je me connecter sur le panel d’administration, avec le compte administrateur créé pendant l’installation, l’authentification est constamment relancé. je dois toujours m’authentifier dès que je clique sur un lien.
J’ai vérifié les droits, tout est fait dans les règles de l’art 
Merci de votre aide
Bonjour,
J’ai recontré ce probléme plusieur fois sans jamais en trouver la vrai cause.
Ce que je peux dire c’est que si c’est un dolibarr héberger recommencer la copie des tout les fichier et assurer vous qu’il passent tous correctement. Vider le cache du serveur et du navigateur. Si c’est chez OVH, oui, ça arrive, et ca se résouds avec un ticket au support client, même si ils disent qu’il ne font rien, le problème se résout « tout seul » après.
Vérifier le paramétrage des cookie de votre navigateur (dolibarr en a besoins).
Si c’est un dolibarr local, (intaller avec DoliWamp) récuprer le .zip de dolibarr et remplacer les fichier par ceux du .zip.
Bonjour,
c’est hébergé chez nous en interne pour la mise en place d’un CRM. j’ai récopié plusieurs les fichiers sans que cela ne résolve quelque chose. Je n’ai rien dans les logs !
Je vais continuer à chercher.
Voilà j’ai enfin trouvé … ça venait d’un problème de configuration d’un fichier php.ini qui surclassait les valeurs par défaut …
Du coup maintenant ça marche bien 
J’ai le même problème sur une installe clean sur un serveur dédié…
Pourrais tu décrire plus précisément ta solution ?
Edit :
Pris par le temps, j’ai fouillé autour de la procédure de connexion, visité le wiki… mais rien de bien folichon à me mettre sous la dent pour tenter de corriger ce truc.
Je vais perdre un client… et vous un promoteur, je m’explique.
Installation de Dolibarr en local pour démonstration (je m’en sers personnellement pour mes comptes), le client est content et demande la même chose chez lui, je lui installe, et hop connexion en boucle inexplicable… le client se fout de ma gueule, moi qui lui vendait Dolibarr comme LE produit de la mort… alors qu’en fait…
Bref, en l’état, soit ça marche dans la journée, soit le client repart sur sa vielle installation de SAGE…
Pour ma part, je ne chercherai plus la solution, je l’attendrai ici et seulement aujourd’hui, une fois ce délais passé, je suis vraiment désolé (et je le pense sincèrement) mais j’irai voir ailleurs.
Radical n’est il pas ?
Ben oui, mais bon, en fouillant dans le code et la base pour essayer de corriger, je découvre sur le cul que le mot de passe est stocké en clair…
Je crois qu’on est dans le « ceci explique cela »… mdp en clair dans la BDD, et combien d’autres trucs complètement hérétiques vous avez incorporé dans Doplibarr ?
Bref, quel gâchis…
On est demain. Donc adieu
Sérieusement ?
Bon…
Drôle de message donc drôle de réponse. Après plus de détails et sûrement que quelqu’un aidera mais pas forcément dans la journée surtout en juillet août.
J’ai bien compris que je ne pourrais pas avoir ma réponse aussi vite, mais il fallait bien que je puisse répondre quelque chose à mon commanditaire…
Bon, ce qui est perdu d’un côté sera récupéré de l’autre…
Je reste dubitatif quant à ce bug très gênant que personne ne semble pouvoir expliquer, et la présence du PSW en clair dans la BDD me laisse à penser qu’il y’a peut être (peut être j’insiste) eu un laissé allé lors de la conception des fondations (même si les deux choses n’ont rien à voir dans les faits, elles se partagent la même origine perfectible).
J’ai installé plusieurs versions (3.6 et 3.7) sur plusieurs serveurs de tests (Ubuntu server 14/04 et 14/10 clean install) et le bug est quand même présent… ce qui me laisse là aussi à penser que vos installations de tests ne sont plus très standards (modifiées, adaptées… à voir) et qu’il serait peut être nécessaire de reprendre cet aspect des choses ?
SI encore j’avais installé Dolibarr sur un serveur particulièrement modifié je dis pas.
Ah oui, je précise avant de me faire lyncher par les ayatollahs barbus et extrémistes :
Je suis un ayatollah, barbu et extrémiste… franco franchouillard et fier de l’être… Linuxo-Machintosheur… admin OS… webmestre… hébergeur…
Et un adage pour motiver les troupes : Qui aime bien châtie bien !
En gros, vous ne trouverez pas beaucoup de commentaires de ma pomme sur les forums des autres produits pour la bonne raison que je ne les utilise pas et surtout que je ne les apprécie pas.
Sous-entendu, j’aime beaucoup Dolibarr qui est mon logiciel de compta perso (ma petite boîte l’aime bien), et malgré quelques petits trucs bizarres (ce &@%*$ de bug et le psw en clair) j’en suis très attaché, pire, en commentant, j’aspire à l’aider à s’épanouir et se corriger, c’est dingue non ? 
P.-S. Conditionnel, tout ça…
P.-S. 2 Je suis un gros balourd et il est hors de question que je me soigne, de toute manière, comme pour tous les Ours mal léchés, il suffit de gratter sous l’oreille pour le faire ronronner
Étonnant.
Le service sur le logiciel libre est un peu basé sur la connaissance fine du logiciel, par seulement de son utilisation (ce qui reste indispensable), mais de par la possibilité d’analyser les tenants et aboutissants d’un (dys)fonctionnement.
Le fait de pouvoir lire le code permet d’aller bien plus loin qu’avec un logiciel propriétaire et, ainsi de pouvoir mieux répondre à son/ses clients.
Configuration > Sécurité > Mot de passe > …
On avance… ou pas !
Quel mot utiliser pour différencier pas de plus ?
Pour la config tu parles bien de ça :
Et donc ? Une très mauvaise fonction activée par défaut devient d’un coup une option géniale parce que le programme propose de la désactiver après coup ?
Inversion des valeurs…
Bref, et cette boucle alors, des idées ?
Je ne suis pas certain que ce soit spécifique à Dolibarr, cette recherche semble aller dans ce sens…
Mot de passe trop long ? Enfin, il apparaît qu’il puisse y avoir plusieurs causes pour le même effet.
Le log n’apporte aucune précision ?
Hm…
Aucun souci avec les autres sites hébergés sur ce serveur.
Pas de souci de cookies non plus…
Le log ? lequel ?
Edit : Non, le mot de passe n’est pas très long, je ne pense pas que cela vienne de là.
Pour les logs de Dolibarr, il faut l’activer dans la Configuration des Modules.
Il y a aussi les logs du serveur proprement dit : apache, mysql, système
Frédéric
Ok, merci pour les tuyaux et les directions de recherches, je vais regarder par là… (quoique rien que pour activer les logs Dolibarr, je vais devoir galérer à me reconnecter toutes les deux secondes)
Désolé pour la coupure de suivis, chuis malade…
Bon, mon client reste intéressé par Dolibarr, il fait confiance à la communauté pour corriger le tir…
Voilà en gros ce qui se passe dans les logs de Dolibarr :
2015-07-25 09:29:26 WARNING 123.45.67.89 main.inc: dolibarr_main_force_https is on but we failed to forge new https url so no redirect is done
2015-07-25 09:29:26 INFO 123.45.67.89 --- Access to /htdocs/admin/index.php showing the login form and exit
2015-07-25 09:29:26 DEBUG 123.45.67.89 --- End access to /htdocs/admin/index.php
Des fois j’ai la fenêtre deux fois de suite, mais pas toujours…
Puis une fois validé :
2015-07-25 09:49:53 WARNING 123.45.67.89 main.inc: dolibarr_main_force_https is on but we failed to forge new https url so no redirect is done
2015-07-25 09:49:53 INFO 123.45.67.89 checkLoginPassEntity usertotest=Admin entitytotest=1 authmode=dolibarr
2015-07-25 09:49:53 INFO 123.45.67.89 functions_dolibarr::check_user_password_dolibarr usertotest=Admin passwordtotest=********** entitytotest=1
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT rowid, login, entity, pass, pass_crypted FROM doli371_user WHERE (login = 'Admin') AND entity IN (0,1) AND statut = 1
2015-07-25 09:49:53 INFO 123.45.67.89 functions_dolibarr::check_user_password_dolibarr Authentification ok - md5 of pass is ok
2015-07-25 09:49:53 DEBUG 123.45.67.89 User::fetch
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT u.rowid, u.lastname, u.firstname, u.email, u.job, u.skype, u.signature, u.office_phone, u.office_fax, u.user_mobile, u.admin, u.login, u.note, u.pass, u.pass_crypted, u.pass_temp, u.fk_societe, u.fk_socpeople, u.fk_member, u.fk_user, u.ldap_sid, u.statut, u.lang, u.entity, u.datec as datec, u.tms as datem, u.datelastlogin as datel, u.datepreviouslogin as datep, u.photo as photo, u.openid as openid, u.accountancy_code, u.thm, u.tjm, u.salary, u.salaryextra, u.weeklyhours, u.color, u.ref_int, u.ref_ext FROM doli371_user as u WHERE u.entity IS NOT NULL AND u.login = 'Admin'
2015-07-25 09:49:53 DEBUG 123.45.67.89 ExtraFields::fetch_name_optionals_label
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT rowid,name,label,type,size,elementtype,fieldunique,fieldrequired,param,pos,alwayseditable FROM doli371_extrafields WHERE entity IN (0,1) AND elementtype = 'user' ORDER BY pos
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT param, value FROM doli371_user_param WHERE fk_user = 1 AND entity = 1
2015-07-25 09:49:53 INFO 123.45.67.89 This is a new started user session. _SESSION['dol_login']=Admin Session id=tqs0tmgf2pnukrmnr05eun6gv0
2015-07-25 09:49:53 DEBUG 123.45.67.89 BEGIN Transaction
2015-07-25 09:49:53 DEBUG 123.45.67.89 User::update_last_login_date user->id=1 UPDATE doli371_user SET datepreviouslogin = datelastlogin, datelastlogin = '20150725094953', tms = tms WHERE rowid = 1
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=UPDATE doli371_user SET datepreviouslogin = datelastlogin, datelastlogin = '20150725094953', tms = tms WHERE rowid = 1
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_20_modPaypal_PaypalWorkflow.class.php' need module to be enabled
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_50_modAgenda_ActionsAuto.class.php' need module to be enabled
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_50_modMailmanspip_Mailmanspipsynchro.class.php' need module to be enabled
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_20_modWorkflow_WorkflowManager.class.php' need module to be enabled
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_50_modNotification_Notification.class.php' need module to be enabled
2015-07-25 09:49:53 DEBUG 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Triggers for file 'interface_50_modLdap_Ldapsynchro.class.php' need module to be enabled
2015-07-25 09:49:53 INFO 123.45.67.89 Interfaces::run_triggers action=USER_LOGIN Launch runTrigger for file 'interface_20_all_Logevents.class.php'
2015-07-25 09:49:53 DEBUG 123.45.67.89 COMMIT Transaction
2015-07-25 09:49:53 DEBUG 123.45.67.89 User::getrights
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT r.module, r.perms, r.subperms FROM doli371_user_rights as ur, doli371_rights_def as r WHERE r.id = ur.fk_id AND r.entity IN (0,1) AND ur.fk_user= 1 AND r.perms IS NOT NULL
2015-07-25 09:49:53 DEBUG 123.45.67.89 User::getrights
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT r.module, r.perms, r.subperms FROM doli371_usergroup_rights as gr, doli371_usergroup_user as gu, doli371_rights_def as r WHERE r.id = gr.fk_id AND r.entity = 1 AND gr.fk_usergroup = gu.fk_usergroup AND gu.fk_user = 1 AND r.perms IS NOT NULL
2015-07-25 09:49:53 INFO 123.45.67.89 --- Access to /htdocs/admin/index.php
2015-07-25 09:49:53 DEBUG 123.45.67.89 Menubase::menuLoad mymainmenu=home myleftmenu=setup type_user=0 menu_handler=eldy tabMenu size=0
2015-07-25 09:49:53 DEBUG 123.45.67.89 sql=SELECT m.rowid, m.type, m.module, m.fk_menu, m.fk_mainmenu, m.fk_leftmenu, m.url, m.titre, m.langs, m.perms, m.enabled, m.target, m.mainmenu, m.leftmenu, m.position FROM doli371_menu as m WHERE m.entity IN (0,1) AND m.menu_handler IN ('eldy','all') AND m.usertype IN (0,2) ORDER BY m.position, m.rowid
2015-07-25 09:49:53 DEBUG 123.45.67.89 --- End access to /htdocs/admin/index.php
Une fois connecté, un clik sur n’importe quel lien me ramène à la fenêtre de log… et ainsi de suite…
Bonjour
Il y a un warning au niveau de https ! Est ce implémenté ?
Si une fois il est en https et une autre fois non ca ne peut fonctionner. Soit vous désactivez, soit vous paramètres correctement.
De plus, je ne lis pas votre configuration ! Version de Dolibarr, apache…
@+
Salut,
Le HTTPS est implémenté oui.
PHP Version 5.5.9-1ubuntu4.9, Apache 2.4.7, MySQL 5.5.43, Dolibarr 3.7.1, le tout sur un Ubuntu Server 14/04
Suite et solution… euh… temporaire.
Malade, du mal à me concentrer, tout ça… je teste un truc, j’attends une heure… bref.
Les logs apaches sont beaucoup plus parlant, en commençant par eux on à la réponse à la première ligne :
[Sat Jul 25 10:00:51.005299 2015] [fcgid:warn] [pid 2454] [client 123.45.67.89:54575] mod_fcgid : stderr: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/home/web/tmp) in Unknown on line 0, referer : https://www.domain.tld/compta/htdocs/admin/modules.php?mainmenu=home
Sur mes serveurs, le tmp est hors racine web avec des droits particuliers.
En le passant en 777 le bug Dolibarr disparaît, mais ce que je ne comprends pas, c’est que PHP accède parfaitement aux sessions en temps normal et que là je ne sais pas pourquoi il achoppe…
Le répertoire tmp est configuré dans le php.ini et il les droits en écriture, bizarre.
Pour le moment je vais laisser en 777, mais j’aimerais quand même revenir au réglage par défaut qui est normalement 770…
À suivre…
Il semble y avoir un soucis avec votre https
Si vous essayez sans https, le problème persiste ?
@+
Je ne peux pas tester sans le HTTPS au niveau serveur, le domaine en question est forcé et il est malheureusement impossible de le désactiver même temporairement, le site est en prod, mais je sais aussi que si le HTTPS ne fonctionnait pas, d’autres scripts me l’auraient déjà dit, IspConfig et RoundCube entre autres, surtout IspConfig qui est forcé aussi sur le HTTPS et qui ne fonctionnerait pas du tout en cas de dysfonctionnement du SSL.
Si je mets le force_https de Dolibarr à zéro, le bug est toujours présent.
J’ai idée (humblement) que Dolibarr utilise les fonctions de sessions de PHP pour enregistrer lui-même l’id de session dans le /tmp, mais je ne trouve pas les fichiers correspondant (malade encore, difficile de me concentrer plus de 10 minutes, tout ça…).
Un simple session_start() suffit pour générer le cookie de session PHP, mais dans ce cas, on utilise la session par défaut de PHP…
Dolibarr utilise sa propre session (ce qui est un très bon point pour lui cela dit au passage), et quand il veut enregistrer la session dans le /tmp il échoue pour cause de droits insuffisants…
C’est pourtant bien Apache / PHP qui exécute la requête, je reste donc quelque peu dubitatif…
À suivre…
