Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MkFramework Discussion :

Problème avec le menu Administration


Sujet :

MkFramework

  1. #1
    Membre confirmé
    Problème avec le menu Administration
    Bonjour,

    J'ai mis en production la bêta de l'outil que j'ai développé ces dernières semaines.

    Pour le contexte système je suis sur un serveur Linux hébergeant le moteur NGINX.
    Mes sources de développement et de production sont sur le même serveur et possèdent les mêmes paramètres dans leurs fichiers respectifs de configuration NGINX.

    Sur mon site de dev tout fonctionne à merveille, sur le site de production il en est de même sauf pour les 4 modules de gestion des droits.
    A savoir users, groups, items et rightsManagerMulti

    Mes différents tests ont démontrés que les droits étaient bien chargés que les sessions étaient différentes,...

    Le seule constat est que lorsque je charge par exemple items::index par l'intermédiaire du menu je ne rentre même pas dans la fonction _index. Alors que si je tape directement l'appel dans l'URL cela fonctionne.
    Même en désactivant la sécurité xsrf le problème persiste.

    Vous me direz c'est bien beau, mais quel est ton problème ?

    J'y viens justement !

    Le problème se manifeste de la sorte :

    Lorsque je m'authentifie, les pages "applicatives" de mon site me donnent accès à l'ensemble des options accessibles par mon rôle d'administrateur.
    Le menu change d'aspect, des boutons cachés font leur apparitions, etc ...

    Le menu Administration contenant les liens vers users::index, groups::index, items::index et rightsManagerMulti::index sont même de la partie.
    Mais lorsque je clique dessus je me retrouve sur la page de Login et cela que sur le site de production.

    Une idée sur l'origine de ce phénomène ?
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein

  2. #2
    Membre confirmé
    Bon,

    J'avance a tâtons :

    J'ai vérifié si mon problème ne venait pas des sessions. Mais a priori j'ai 2 fichiers sessions différents qui se crée donc j'en déduis que le système distingue bien les 2 sites.

    Je me suis donc focalisé sur la chaîne d’authentification en commençant par le main du module Auth et du retour de la page Login.

    J'ai donc glissé dans la fonction checkLoginPass un petit var_dump
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
     
    $oUser=_root::getAuth()->getAccount();
    echo '<PRE>';var_dump($oUser);echo '</PRE>';die();


    J'ai obtenu ce à quoi je m'attendais. La sortie du code étant un redirect vers une page public.

    J'ai vérifié le comportement dans le main du menu, pour glisser un autre var_dump
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
     
    echo '<PRE>';var_dump(_root::getAuth()->getAccount());echo '</PRE>';die();
               if(_root::getAuth() and _root::getAuth()->getAccount()){
     
                    $tAuthLink=array('Se déconnecter' => 'auth::logout');
               }else{
                   $tAuthLink=array('Se connecter' => 'auth::login');
               }


    Et celui-là devrait me retourner exactement la même chose que le précédent et pourtant non ! J'ai un beau NULL

    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein

  3. #3
    Rédacteur

    Bonjour,
    question: vous avez bien activé auth.enabled ?

    autre chose, je connais peu nginx, vous avez des logs dessus ?

    quel version de php ?

    vous pouvez avoir un soucis php qui affiche une erreur provoquant le crash lors de l'ecriture/lecture de session avec "header already sent..."
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  4. #4
    Membre confirmé
    Salut,

    Désolé, J'étais sur d'autres projets je n'ai pas eu le temps de me pencher sur la réponse de ce post.

    Je confirme le Auth est bien activé et mon site de PROD est un clone GIT de mon site de DEV où tout fonctionne à merveille.

    Le phénomène est assez incompréhensible :
    L'ensemble des menus qui demandent un droit d'accès reconduisent vers la page de login et malgré la réussite de l'authentification je boucle sur le la page de Login.

    J'ai regardé les fichier Session du côté PHP et ils se remplissent et se vident en fonction du login ou du logout. Preuve que l'authentification fonctionne.

    La majorité des modules restreints sont soumis à la condition :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    if( (_root::getConfigVar('auth.enabled')==1) and (!_root::getACL()->can('Access','module::action'))){
                        _root::redirect('locbiv::list');
                }


    Cependant, j'ai remarqué que certain module qui me retournent sur le page de login n'ont pas de condition d'accès.
    Autre point non négligeable mon menu est dynamique en fonction des accès. Un utilisateur non connecté n'aura accès qu'aux pages "public" (celles déclarées dans module.disabled.list de site.ini.php) et son menu sera donc adapté.

    Dans ces menus j'ai justement une liste ayant une restriction de droit. Comme elle fait partie d'un module "public" le lien qui pointe sur cette liste est constamment visible. Si bien que lorsque je fais mon authentification les modules restreint ne fonctionnent pas alors que cette liste du module public fonctionne.

    J'ai ajouté un debug pour suivre mes conditions.

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    <?php 
                        plugin_debug::addSpy('Valeur de getAuth', _root::getAuth());
                         plugin_debug::addSpy('Valeur de getAccount',_root::getAuth()->getAccount());
                        ?>


    J'obtiens le même résultat que si je n'étais pas connecté et rien dans getAccount.

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    plugin_auth Object
    (
        [oAccount:plugin_auth:private] => 
        [_bConnected:abstract_auth:private] => 
    )


    On dirait que suite à mon authentification je suis immédiatement déconnecté, mais ce n'est pas le cas puisque le session PHP reste rempli et que le lien restreint du module public reste accessible.
    Chose que nous savions déjà puisque getAccount() trouve ce qu'il cherche dans la $_SESSION.

    Ce qui se confirme encore si je rajoute l'un des modules retreint dans la liste des modules désactivés (module.disabled.list) celui-ci est accessible et les actions (edit, new, delete) sont masqué ou visible en fonction que si la session est ouverte ou fermée.

    Une piste ?
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein

  5. #5
    Rédacteur

    Une piste peut etre que le problème lié à la desactivation de la session juste après la redirection

    essayez de modifier la valeur dans le ficheir de config conf/site.ini.php


    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    [security]
    (...)
    xsrf.checkReferer.enabled=1


    passez cette variable à 0, ça verifier si le referer est différent du site, ce qui peut arriver sur une redirection au login sur certains navigateur/paramères

    dites moi, si ça corrige votre soucis


    Pour informaiton, une manière de debuguer c'est d'activer le log applicatif
    Dans le meme fichier, activer le logi
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    [log]
    class=plugin_log
    application=0
    warning=0
    error=0
    information=0

    Mettez information à 1 et vous verrez dans data/log beaucoup de detail qui peuvent aider
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  6. #6
    Membre confirmé
    Comme toujours tu as mis le doigt là où il fallait.
    Quand je désactive le xsrf.checkReferer j'ai mes accès qui fonctionnent correctement.

    ça ne m'explique pas pourquoi ça fonctionne en DEV et pas en PROD.

    Quand aux logs ils racontent énormément de choses.

    Il semblerait que j'ai un problème sur mes ACL. Le scénarios de test a été déroulé de la sorte :
    Session Vide -> Authentification -> Authentification réussie -> Accès au menu UserList. (Fichier 1,2,3 et 4 de la PJ de ce post.) Le fichier 5 est l'accès au menu avec xsrf.checkReferer à 1
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein

  7. #7
    Rédacteur

    Pour la différence DEV, PROD? ce sont des serveurs différents avec un configuration différente je suppose ?

    Pour les ACL

    je remarque une chose bizarre

    Ouverture login
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    2020-06-29;09:10:37;info;ACL can "Access" on "users::listUsers" ? : non


    VS

    Acces menu users
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    29/06/2020;09:12:48;info;"ACL can ""Access"" on ""users::listUsers"" ? : oui"


    ce double apostrophe m'interpelle, vous auriez un endroit ou vous faire une can() différent avec des quotes en trop ?
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  8. #8
    Membre confirmé
    Salut,
    Mes deux instances sont bien sur le même serveur.
    Je viens de vérifier mon code et Je n'utilise que des Simple Quote, les Double Quote ne sont pas de mon fait d'autant plus que je ne les trouves pas dans mes fichiers CSV.

    Je viens de comprendre pourquoi on retrouve plusieurs fois la ligne "Access" on "locbiv::deleteBiv" ? : oui. dans les fichiers de log ( exemple 3_Authentification.csv). Je construit ma liste d'éléments avec des liens d'actions soumis aux ACL. Je vais modifier mon code pour ne les appeler qu'une seule fois.

    Mais cela n'explique toujours pas pourquoi on a un problème lorsque le filtre xsrf est actif...
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein

  9. #9
    Rédacteur

    Le check xsrf vérifie que le HTTP_REFERER est égal au domaine courant

    vous pouvez à la page de suite après login faire un print du tableau de _SERVER et quitter

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
     
    var_dump($_SERVER); exit;


    et regardez la différence entre votre environnement dev et prod pour voir quel est la différence dans ce champ
    il compare par rapport à la valeur dans SERVER_NAME

    c'est peut etre ça qui peut changer entre les 2 modes dev et prod
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  10. #10
    Membre confirmé
    Bingo ! Tu as trouvé.
    Si je passe par le nom alias de mon site j'ai un problème d'authentification.
    Je vais faire en sorte que mon Alias soit rediriger sur mon server_name.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !


    Albert Einstein