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 ?

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:

---

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:

---

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

:weird:

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..."

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:

---

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:

---

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:

---

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 ?

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:

---

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:

---

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 ;)

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

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:

---

2020-06-29;09:10:37;info;ACL can "Access" on "users::listUsers" ? : non

---

VS

Acces menu users

Code:

---

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 ?

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...

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:

---

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

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.