Impossibilité de s'authentifier

[julien@quai13]

Salut salut,

j'ai un bug qui est remonté 3 fois (1 fois il y a 2 mois, hier, et il y a 1h) sur AndCo concernant l'impossibilité de se connecter, la tentative de connexion renvoyant en boucle sur le formulaire de connexion.
- Le bug ne provient pas du navigateur puisqu'il a été remonté sur Firefox et IE.
- Le bug ne provient pas du blocage des cookies puisqu'il n'y en a pas sur le site.
- Le bug ne provient pas d'un site en particulier puisqu'il est apparu sur DEMO et en PROD.
- Le bug ne provient pas d'un compte en particulier puisqu'un DO, un STT, et JJL ont été touché.
- Le bug doit provenir de Clementine puisque les fonctions concernées ne sont pas surchargées.

Je pense à une configuration réseau particulière puisque les 3 fois cela est arrivé en entreprise (chez Chronopost, chez GLS, et chez un STT qui avait un informaticien donc une gestion du réseau) mais je ne vois pas du tout ce que ça pourrait être.
EDIT : sur le même réseau la connexion à DEMO posait problème mais pas pour accéder à PROD.
Pour l'instant un renouvellement du mot du passe a permis la résolution du mot du passe sauf dans le cas de JJL, car étant sur DEMO c'est moi qui recevait les mails donc qui ait effectué la renouvellement du mdp sur mon poste. Ca ferait penser que le renouvellement du mot de passe doit être associé avec l'ip qui a rencontré le bug pour que celui-ci soit résolu.

Donc là je sèche et comme je ne suis pas spécialiste réseau, je me demandais si tu n'avais pas une explication rationnelle ou un début de piste. Si j'ai d'autres infos je viendrais éditer.

[pa-de-solminihac]

Tu as activé le debug ? Tu reçois une alerte par mail ? Tu arrives à reproduire le bug ? Si tu as un rapport d'erreur Clémentine, envoie

Ca me semble étrange que ce soit un problème de réseau. Je me demande si ça ne pourrait pas avoir un rapport avec les réglages du navigateur. Par exemple, il faudrait tester en ayant configuré le navigateur pour refuser les cookies. Si ca se trouve, sans cookies il n'y a plus de transmission du PHPSESSID, et ça pourrait être lié ?

[julien@quai13]

Debug activé sur les 3 sites pour mon IP en permanence.
Aucun email, vu que l'impossibilité de s'authentifier n'est pas une erreur en soi.
Comme il est apparu 3 fois en 2 mois et que j'ai aucun paramètre commun dans les 3 fois où il est survenu impossible de le reproduire.
Si ça se reproduit j'essayerai de bloquer les cookies, mais sur le même navigateur et poste, JJL n'arrivait pas à se connecter sur DEMO mais aucun problème quand il a essayé sur le site de PROD.
Je me suis fais les commentaires de php.net sur les fonctions session_id et session_regenerate_id mais à priori ça ne vient pas forcément de là.

Elle est choucave celle-là ou pas ?

[pa-de-solminihac]

Je confirme, j'arrive à reproduire le problème en désactivant les cookies. Pas sûr qu'il y ait une solution simple à mettre en oeuvre. Étant donné qu'on utilise de toute façon les cookies, la meilleure chose à faire à mon avis est de détecter que l'utilisateur n'a pas activé les cookies et de le prévenir qu'ils sont nécessaires au bon fonctionnement du site.

Tu peux peut être t'inspirer du module ie6nomore pour faire ça dans un module indépendant (app/share) plutôt que de le faire dans le code du site (app/local) ?

[julien@quai13]

Où sont utilisé les cookies ? Si je fais un grep '$_COOKIE' il en sort seulement 4 utilisé pour la div de debug et fonctions $request, mais rien lié aux sessions.

Et d'ailleurs je ne reproduis pas vraiment le bug. J'ai lancé IE en navigation privé après avoir vider l'historique, les cookies, le cache, enfin la totale : sur plusieurs tests, il m'est arrivé seulement 2 fois de tomber sur la page de connexion, à la deuxième tentative j'étais loggué.
Ca à l'air effectivement de "gêner" un peu mais on est loin de la situation où les utilisateurs ayant rapporté le bug n'ont jamais pu se connecter même en insistant des dizaines de fois.
Sinon oui bien sûr un bug gênant comme ça, sera corrigé dans Clementine. Ca tombe bien je commence à avoir un peu de marge sur les tickets (pour le moment).

Merci de tes retours en tout cas !

[pa-de-solminihac]

Quand je parle de désactiver les cookies je veux dire "configurer le navigateur pour qu'il refuse les cookies". Pas juste les effacer

Selon la façon dont il est configuré, PHP utilise les cookies pour transmettre l'id de session PHPSESSID d'une page à l'autre lors de la navigation. Cela permet de ne pas le passer par le biais de l'URL. C'est plus sécurisé et ça éviter des URL qui vont générer du duplicate content.

Pour en savoir olus, jette un oeil à la doc PHP, à propos des paramètres suivants :
- session.use_trans_sid
- session.use_cookies
- session.use_only_cookies

[julien@quai13]

C'est bien à cela que sert le mode navigation privé ^^

La navigation InPrivate empêche Internet Explorer d’enregistrer des données relatives à votre session de navigation. Ceci inclut les cookies, les fichiers Internet temporaires, l’historique et les autres données. Les barres d’outils et les extensions sont désactivées par défaut.

De toute façon le problème ne vient pas de là puisque JJL ne peut encore pas accéder à DEMO (mais à PROD oui), pourtant les cookies sont bien activés sur le navigateur du poste (2 fois qu'il est en réunion chez GLS, 2 fois qu'il ne peut pas se co sur DEMO :/ )
Vu que c'est DEMO qui a l'air le plus concerné je vais voir s'il n'y a pas une différence de conf' entre DEMO et PROD.

[pa-de-solminihac]

Je connais mal le mode de navigation privée de IE, j'utilise peu ce navigateur. En revanche, sous Firefox, le mode de navigation privé se présente un peu de la même manière :

Dans une fenêtre de navigation privée, Firefox ne conservera aucun historique de navigation, de recherche, de téléchargement, de formulaire web, de cookies ou de fichiers temporaires Internet.

Ce que ça veut dire, c'est que les cookies, fichiers de cache, etc... ne seront pas conservés hors de la navigation privée. La subtilité, c'est que cela n'empêche pas le navigateur d'accepter les cookies pendant la navigation privée. Ça fait juste qu'il ne les conservera pas après. Je suspecte fortement qu'IE fonctionne de la même manière.

Pour reproduire le bug systématiquement, ouvre Firefox (ça me fera plaisir ), va sur demo et fais Ctrl+I (ou clic droit > informations sur la page), puis dans l'onglet "Permissions" > "définir les cookies" clique sur "Bloquer".

Tu peux enfin tester, et reproduire le problème.

[julien@quai13]

Gnarf j'ai tout paramétré en mode hyper-restrictif (sur IE parce qu'en entreprise c'est le plus utilisé), et oui je reproduis bien le problème en boucle.
Par contre concernant JJL c'est plus étrange vu que lui c'est seulement un site sur 2 qui bloque, normalement ça ne devrait être soit tout soit rien.
Et je n'ai toujours pas trouvé où tu utilisais les cookies.

Je viens de finir un correctif pour la function loginAction de Clementine, c'est basique mais ça fais le job :

Code : Tout sélectionner

public function loginAction($request, $params = null)
    {
        setcookie('andco-cookie', 'andco-cookie');
        if (isset($_COOKIE) && !empty($_COOKIE)) {
            $ns = $this->getModel('fonctions');
            $this->data['message'] = "Connexion requise";
            // Traitement de la demande de login
            $url_retour = $this->getModel('fonctions')->ifGet('html', 'url_retour', null, __WWW__, 1, 1);
            if (!empty($_POST)) {
                // collect the data from the user
                $login    = $ns->strip_tags($request->POST['login']);
                $password = $ns->strip_tags($request->POST['password']);
                if (empty($login)) {
                    $this->data['message'] = 'Vous devez fournir vos identifiants pour accéder à cette page';
                } else {
                    $this->login($login, $password, array('url_retour' => $url_retour));
                }
            }
            // NOTE : on ne redirige pas si l'utilisateur est deja authentifie...
            // car on créerait une boucle de redirection
            // (puisqu'il n'aurait pas du être redirigé ici)
            // render de la vue
            $this->data['url_retour'] = $url_retour;
        } else {
            $this->data['message'] = '<p><span style="color:red;">Vous devez activer les cookies pour pouvoir vous connectez.</span> Merci de votre compréhension.</p>';
            $this->data['message'] .= '<label class="information">Activer les cookies pour :<ul>';
            $this->data['message'] .= '<li><a href="https://support.google.com/accounts/answer/61416?hl=fr">Google Chrome</a></li>';
            $this->data['message'] .= '<li><a href="http://support.mozilla.org/fr/kb/activer-desactiver-cookies">Mozilla Firefox</a></li>';
            $this->data['message'] .= '<li><a href="http://windows.microsoft.com/fr-fr/windows7/block-enable-or-allow-cookies">Internet Explorer</a></li>';
            $this->data['message'] .= '</ul></label><br />';
        }
    }


Si ça convient je mettrai en ligne (ce qui promet d'être fun).

[pa-de-solminihac]

Je n'utilise pas les cookies moi même, c'est PHP qui utilise tout seul comme un grand les cookies pour passer l'id de session entre les pages. C'est dans le php.ini, regarde dans la doc ce que font les paramètres suivants si tu veux en savoir plus :
- session.use_trans_sid
- session.use_cookies
- session.use_only_cookies

Pour ton correctif, je te conseille une bonne pratique : quand tu surcharges une fonction dans Clémentine, chercher toujours à le faire d'une manière qui te permette d'appeler dans ta surcharge la fonction parent::mafonction(mesparams);

C'est important, pour plusieurs raisons :
- si tu ne suis pas cette pratique, si l'implémentation de la fonction que tu surcharges change (lors d'une mise à jour d'un module share par exemple), tu risques de perdre la compatibilité.
- si tu ne suis pas cette pratique, et que plusieurs modules surchargent cette fonction, ta surcharge prend le pas sur toutes les autres. Par exemple si tu as un module qui log dans un fichier texte le fait qu'un utilisateur s'est connecté, un autre qui t'envoie un mail quand un utilisateur se connecte (ce qui serait très chiant mais c'est pour l'exemple), et que tu fais ta surcharge sans suivre cette pratique, seule ta surcharge sera utilisée, ce qui neutralisera le log et l'envoi de mail.

C'est une notion importante, je ne sais pas si mon explication est claire... n'hésite pas si tu as besoin que je l'améliore