Pb de redirection avec le plugin Vip-zone

Paul · 8 avril

Bonjour,
J'ai presque terminé de reconfigurer mon site en basculant sur me plugin Vip-zone. Il va me permettre de mieux sécurité les parties privées.
Toutefois, les redirections erronées lors des connexions et des déconnexions. L'adresse qui s'affiche est _[MON_SITE]/core/admin/auth.php?p=/[MON_SITE]//core/admin/?

J'ai bien placé Vip-zone en tête des plugins

Merci de votre aide
Paul

gcyrillus-nomade · 8 avril

Bonsoir,

Si c'est en local et que vous avez plusieurs instances et onglet avec PluXml ouverts, il peut arrivé que le navigateur fasse un cafouillage au niveau des cookies. Si c'est le cas, effacer les cookies. Ensuite , utiliser deux navigateurs différents de façon à ne pas re-provoquer un cafouillage au niveau des cookies. (un nav pour le dev et un nav pour le test) .

Si ce n'est pas le cas, indiquez moi:
1. version de PluXml
2. lien de l'archive que vous avez télécharger / version
3. version de PHP initialement devellopé en php 7.X / serveur Apache )
4. éventuellement les autres plugins en cours.
5. htaccess ou pas ? (le ? tout seul me fait penser à un soucis d'url rewriting pas courant mais je n'y crois pas trop)
6. Est-ce suite à un mauvais mot de passe ou un rafraichissement de la page de login ?

de façon a ce que je puisse voir en local avec une configuration similaire à la votre ce qui cloche , cela ressemble à une agaçante mise en orbite.

cdt

Paul · 9 avril

Bonjour,
Merci pour votre aide pour faire un bon diagnostic.
J'arrive à avoir un fonctionnement correct de Pluxml en local.
Je retiens l'hypothèse d'un cafouillage au niveau des cookies. J'ai effectué de multiples tests avec trois navigateurs différents.
et j'ai plusieurs sites herbergés chez IONOS dans différents sous-repertoires qui fonctionnaient bien avant d'ajouter un nouveau site en dev.
Je viens de constater un problème similaire sur mes sites en production.

Existe-il des cookies internes chez IONOS ?
Mes fichiers htaccess sont seulement destinés à limiter les accès indésirables. Faut-il ajouter les instructions pour mieux gérer l'url rewriting ? Si oui, que dois-je écrire.

Par ailleurs, j'ai personnalisé ma page d'accueil selon que l'on soit connecté ou pas en adaptant dans le thème les fichiers home.php et sidebar.php selon l'existence de $_SESSION['profil'].

Cordialement
Paul

gcyrillus-nomade · 9 avril

Bonjour,

Pour les fichiers htaccess ils ne sont pas fautifs
Les cookies de IONOS, non plus sauf si on a des clés/valeurs similaire, c'est peu probable.
Pour le filtrage via $_SESSION['profil'] , idem pas d'incidence et c'est la façon de faire.

Sur un même domaine(et ses sous domaine) pour éviter une interférence de cookies de session, il faut utiliser des logins différents pour chaque site/instance de PluXml (avec ou sans plugin) . En sous répertoire sur un même domaine , le risque est le même, le navigateur risque de mélanger les clés/valeurs, c'est ce que je faisais en local, la récupération d'un site avec des sous-domaine et plusieurs PluXml , m'ont fait une piqure de rappel (pas de VIP-Zone installé, juste la connexion à l'admin). Je vais voir pour me renseigner pour voir comment eviter ces cas de figures._{(en fait, tout les cookies similaires sont renvoyés au navigateur, d'où une incompréhension du navigateur au moment de les gérer)}

Cdt

gcyrillus-nomade · 15 avril

@paul Après quelques recherches et ce défaut commun avec les sessions (pas seulement le plugin, mais juste l’accès à l'administration) lorsque que l'on à plusieurs instance de PluXml sur le même serveur, domaine et sous-domaine, on se trouve très vite dans une situation de télescopage des cookies de session.
Une solution serait probablement de donner un nom unique à la session en fonction de l'adresse et répertoire racine de chaque PluXml.

Cela se passerait dans prepend.php sur la portion suivante:

# On démarre la session
session_start();
setcookie(session_name(),session_id(),time()+SESSION_LIFETIME, "/", $_SERVER['SERVER_NAME'], isset($_SERVER["HTTPS"]), true);

$session_domain = __DIR__ ;

if(!defined('PLX_AUTHPAGE') OR PLX_AUTHPAGE !== true){ # si on est pas sur la page de login
    # Test sur le domaine et sur l'identification
    if((isset($_SESSION['domain']) AND $_SESSION['domain']!=$session_domain) OR (!isset($_SESSION['user']) OR $_SESSION['user']=='')){
        header('Location: auth.php?p='.htmlentities($_SERVER['REQUEST_URI']));
        exit;
    }
}

Cela pourrait être une évolution de PluXml

Exemple possible pour nommer la session : session_name(basename(realpath(PLX_ROOT))); à mettre juste devant session_start(); et à condition, que le server/php ne soit pas configuré pour lancer une session automatiquement.

Cela donnerait (et sans garantie)

# On nomme la session
session_name(basename(realpath(PLX_ROOT))); // peut-être vérifier et nettoyer des caractères indésirables en amont

# On démarre la session
session_start();
setcookie(session_name(),session_id(),time()+SESSION_LIFETIME, "/", $_SERVER['SERVER_NAME'], isset($_SERVER["HTTPS"]), true);

$session_domain = __DIR__ ;

if(!defined('PLX_AUTHPAGE') OR PLX_AUTHPAGE !== true){ # si on est pas sur la page de login
    # Test sur le domaine et sur l'identification
    if((isset($_SESSION['domain']) AND $_SESSION['domain']!=$session_domain) OR (!isset($_SESSION['user']) OR $_SESSION['user']=='')){
        header('Location: auth.php?p='.htmlentities($_SERVER['REQUEST_URI']));
        exit;
    }
}

cdt

Paul · 17 avril

Merci pour votre proposition.
Je commence à faire des tests. Mais ce n'est pas simple.
Est-il possible de limiter la durée sur les cookies de connexion ?
Cordialement

gcyrillus-nomade · 17 avril

Bonjour,

La durée des cookies est definie dans le fichier : core/admin/prepend.php .C'est la ligne const SESSION_LIFETIME = 7200;;

Cdt

Paul · 18 avril

Bonjour,
J'ai resté la proposition de nom unique à la session en fonction de l'adresse et répertoire racine de chaque PluXml.
Je pense qu'il faudra regarder les différents redirections. Le simple ajout entraîne des perturbations. Par exemple :

un VIP qui veut consulter une page statique VIP, est envoyé sur la page d'administration du site
lors de la rédacteur d'un article, la prévisualisation ne s'affiche pas
pour la gestion des utilisateurs, la modification des droits est mal prise en compte.
etc...

Bon courage

gcyrillus-nomade · 18 avril

Bonjour @Paul

Alors,** j'ai quand même besoin de connaitre** ta version de php et de PluXml, ainsi celle du plugin que tu as installé. Car ce que tu décris m’étonne.
Y-a t-il d'autre plugin que tu utilises qui se servirait aussi des sessions/profils ?

Ce plugin créer un nouveau profil :VIP . Celui-ci n'a aucun droit sur l'admin et à une utilité sur les pages 'privatisé' de PluXml.
Démo: http://gcyrillus.free.fr/new/ login: vip - pass: vip (plux 5.8.7 / php 5.6 )
Tester aussi en php7.x et 5.8.9 . tester aussi avec php 8.1.5

Il n'y a q'un profil VIP qui est redirigé vers la page en front protégée si il a voulu la consulté sans être connecté, tout autre profil est simplement logué à l'admin (le plugin n'intervient que pour une page protégée et interdis l'admin si le profil en court est un VIP)
Pour les autres profils : aucune interférence coté admin et il sert les pages en front quelque soit le profil logué.

Un VIP ne peut pas accéder au pages de l'admin, sauf si entretemps, tu as modifier les droits de cet utilisateur et ce n'est plus un VIP .

La proposition de nom de session est soit une mauvaise idée soit mal pensé du coup. Mais ce n'est pas intimement lié au plugin, le plugin utilise le système de session de PluXml existant. La seule modif est l'ajout d'un profil qui peut-être stocké dans le cookie de session. Au moment de se logué, le VIP est renvoyé vers la page qui l'a rediriger vers le formulaire de connexion. Un profil natif de PluXml affichera l'administration.

Cdt

Paul · 18 avril

Bonsoir,
Je suis parvenu à un fonctionnement conforme à ton site de démo en local sous wamp.
Je vais tenter de me approcher progressivement de configuration de mon site de production.
A savoir :
Mon hébergement chez IONOS PHP 8.1
avec PluXml version 5.8.9,
et des plugins:

Espace Privé - Version 2.0.1 (18/10/2021)
MyContacts - Versoin 1.8.1 (10/04/2017)
MySlippry - Version 1.2.1 (10/04/2017)
plnCalendrier - Version 2.1.0 (10/04/2017)
plxEditor - Version 1.6 (29/01/2019)
plnStactPages - Version 1.0.3 (12/07/2020)

.htaccess

RedirectMatch permanent ".*/[0-9]+-[^/]+$" "/index.php"
# BEGIN -- Pluxml
Options -Multiviews

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
# Réécriture des urls
RewriteRule ^(?!feed)(.*)$ index.php?$1 [L]
RewriteRule ^feed/(.*)$ feed.php?$1 [L]

# END -- Pluxml

Cordialement

gcyrillus-nomade · 19 avril

Merci de ton retour,

Je vais regardé pour me faire une config similaire, mais je ne suis pas certain que plnCalendrier soit fonctionnel en php 8.1

cdt

Paul · 20 avril

Bonjour,
J'ai testé avec les différentes versions PHP.
En local avec Wamp, les versions 8.0.26 et 8.1.13 marchent très bien pour les plugns Vip-zone et plnCalendrier.
En version 8.2 les liens ne marchent plus tant avec Vip-zone qu'avec plnCalendrier.
Chez mon hebergeur, les liens ne marchent pas sur 8.0, 8.1 et 8.2

Cordialement

gcyrillus-nomade · 20 avril

Okay,

Le plugin est dans l'état, incompatible avec l'urlrewriting. Il y a une incompatibilité avec la redirection htaccess et celle du plugin redirigeant vers le formulaire de connexion (ces deux redirections se mettent en orbite mutuellement)Le plugin est passé en version 2.0.2

alors sous php 8.2.5 , il y a effectivement un bug du a une mauvaise utilisation des quotes.
Dans le fichier vip_zone.php
remplacer la fonction ThemeEndHead() par celle ci avec les typos corrigées ou récupérer le fichier sur github (je viens de faire la mise à jour, qui devrait aussi régle les versions 8x de ton hébergeur et le cas de l'urlrewriting activé) .

        #Avant l'affichage de la page, on verifie si il y a besoin d'authenfication en comparant la configuration du plugin et le type de page demandée
        public function ThemeEndHead() {    
        echo self::BEGIN_CODE;
?>
          # On recupere le mode privatisé
          $plxMotor = plxMotor::getInstance();
          $plugin = $plxMotor->plxPlugins->aPlugins['vip_zone'];
          $parameter = $plugin->getParam('privatize');

          #Selon le mode privatisé, on redirige vers la page d'authenfication si par encore logué
          if($parameter =="catart") {
                if (!isset($_SESSION['profil']) && (($plxMotor->mode === 'categorie' ) || ($plxMotor->mode === 'article' ))) {
                    $_SESSION['pageRequest']= $_SERVER['REQUEST_URI'];
                    header("Location: ".$plxMotor->urlRewrite(PLX_ROOT."core/admin/"));
                    exit;
                }
        }
          else if ($parameter =="static") {
                if (!isset($_SESSION['profil']) && ($plxMotor->mode === 'static' )) {
                    $_SESSION['pageRequest']= $_SERVER['REQUEST_URI'];
                    header("Location: ".$plxMotor->urlRewrite(PLX_ROOT."core/admin/"));
                    exit;
                }
        }   
          else if ($parameter =="blog") {
                if (!isset($_SESSION['profil']) && (($plxMotor->mode === 'home' ))) {
                    $_SESSION['pageRequest']=$_SERVER['REQUEST_URI'];
                    header("Location: ".$plxMotor->urlRewrite(PLX_ROOT."core/admin/"));
                    exit;
                }
        }
<?php
        echo self::END_CODE;
        }

Pour plcalendrier, je t'ai répondu dans ton autre fil : https://forum.pluxml.org/discussion/comment/63735/#Comment_63735
(note que le passage à php 8.2.x nécessite la même astuce pour plxEditor)

Cdt

Paul · 24 avril

J'ai toujours de problème de redirection
Quand je suis sous l'écran de connection, Firefox donne le message suivant :

Le cookie « PHPSESSID » n’a pas de valeur d’attribut « SameSite » appropriée. 
Bientôt, les cookies dont l’attribut « SameSite » est manquant ou défini avec une valeur invalide seront traités comme « Lax ». 
Cela signifie que le cookie ne sera plus envoyé dans des contextes tiers. 
Si votre application dépend de la disponibilité de ce cookie dans de tels contextes, veuillez lui ajouter l’attribut « SameSite=None ». 
Pour en savoir plus sur l’attribut « SameSite », consultez [https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite auth.php](http:// "https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite auth.php")

Merci de me proposer une solution

Cordialement
Paul

gcyrillus-nomade · 24 avril

Bonjour,

@Paul
Comme indiqué précédemment, les cookies sont créer et gérer par PluXml , Il n'y a donc pas de mise à jour possible à faire à partir du plugin.Le plugin test la session et ne fait pas d'appel direct au cookie généré par PluXml au moment de la connexion

Firefox nous indique ce message depuis longtemps déjà et chrome s'y est aussi mis dés sa version 80 je crois.

Le samesite attribut, n'a aussi que de sens sur une connexion en https

Une modif possible en php >7.3 (à faire dans prepend.php dans le repertoire core/admin de pluxml)

A ne pas utiliser sur version inférieur à php 7.3 .

# On démarre la session
session_start();
setcookie(session_name(), session_id(), [
  'expires' => time()+SESSION_LIFETIME,
  'path' => '/',
  'domain' => $_SERVER['SERVER_NAME'],
  'samesite' => 'None',
  'secure' => true,
  'httponly' => true
]);

Selon la version de PHP, la syntaxe/injection des données de cookie n'auront pas la même syntaxe.
Si vous n’êtes pas sur de vous, gardez le code original de PluXml et ignorez le message à propos du samesite, il n' y aura pas d'incidence sur votre connexion à l'administration ou au front pour des pages privatisées ou autre plugin utilisant aussi session et cookie

Cdt,

Si un expert passe par là, ne pas hésiter à intervenir

EDIT

Pour faire plus simple quand au choix à faire , on peut aussi filtrer la version de php

session_start();
if(PHP_VERSION_ID < 70300) {
    setcookie(session_name(), session_id(), "/; samesite=none",$_SERVER['SERVER_NAME'], true, true);
} else {
    setcookie(session_name(), session_id(), [
      'expires' => time()+SESSION_LIFETIME,
      'path' => '/',
      'domain' => $_SERVER['SERVER_NAME'],
      'samesite' => 'None',
      'secure' => true,
      'httponly' => true
    ]);
}

À noter que dans index.php à la racine, on pourrait aussi faire la même manip

# On démarre la session
//session_set_cookie_params(0, "/", $_SERVER['SERVER_NAME'], isset($_SERVER["HTTPS"]), true);
if(PHP_VERSION_ID < 70300) {
    session_set_cookie_params(0, '/; samesite=none', $_SERVER['SERVER_NAME'], true, true);
} else {
// note I use `array()` instead of `[]` to allow support of php <5.4
    session_set_cookie_params(array(
        'lifetime' => 0,
        'path' => '/',
        'domain' => $_SERVER['SERVER_NAME'],
        'secure' => true,
        'httponly' => true,
        'samesite' =>'none'
    ));
}
session_start();

Paul · 25 avril

Bonjour,
Ouf, ça va mieux
Vous pouvez voir le site de ma chorale : http//trinitoust.bodieu.fr
Il est paraît assez sécurisé. J'ai mis quelques explication : trinitoust.bodieu.fr/static35/creer-une-site-internet-pour-une-autre-chorale

Il manquait quelques** exits**; après ** header('Location: ' ...");**

Mais je pense qu'il faudrait remplacer les header('Location: ' ..."); par la balise meta http-equiv="refresh" content="0;url=...."
Cela me paraît plus sûr.
Pour mes pages statiques privées, j'ai mis en première ligne :

‹?php if (!isset($_SESSION['profil']) ) {$_SESSION['pageRequest'] = $_SERVER['REQUEST_URI'] ; ?›
‹meta http-equiv="refresh" content="0;url=/core/admin/auth.php"› ‹?php die();} ?›

Il reste à voir les pages blanches après connexion.

J'ai testé sur différentes versions Php 8 avec Firefox et Chrome sans problème. Par Safari gère mal le deuxième niveau des pages statiques.

Merci pour votre aide.

gcyrillus-nomade · 25 avril

Je ne suis pas convaincue par les meta refresh.

Si tu veut tester en remplaçant la ligne 106 et la ligne 171 par

f(isset($_SESSION['profil']) and $_SESSION['profil'] === '5')  {  echo '<meta http-equiv="refresh" content="0;url='.$_SESSION['pageRequest'].'">';}

Le test if() sur hook AdminPrepend peut-être retirer dans ce cas(ligne 106), il est doublé avec AdminTopEndHead (ligne 171).

Pour les pages blanches , aucunes idées du pourquoi/comment. (pas encore vu ce défaut)

P.S. maj de la ligne 106 et 171 sur le repos .pas de <meta http-equiv="refresh" injecté. L'accès à l'admin même pour une fraction de seconde n'est pas une bonne idée.

Reste en suspend la gestion des moteurs de recherches , interdiction de l'indexation des pages privatisées(logique) ?

cdt

Paul · 26 avril

Bonjour,
J'ai commencé à remplacer, dans vip-zone.php, les "Head(location..". par "meta http-equiv="refresh...".
En supprimant le bloc ligne 106 et en modifiant la ligne 171. Je ne mois pas d'impact.
Il me faut aussi modifier les lignes 121, 126, 210, 217, 210.
Pour l'instant, la 1ère ligne du fichier de la page statique reste avec Head(location...

J'ai plusieurs modifications à faire sur mon site de production qui peut déjà reprendre de l'activité.
Je vais y aller plus lentement sur les "meta http-equiv="refresh...".

Pour ma part, je ne suis pas favorable au moteur de recherche sur les pages privatisées. Il existe les catégories et les mots-clés. Sur mon site il faut être connnecté pour qu'il s'affiche. (J'ai mis un test dans le fichier sidebar.php du thème.

Cordialement

gcyrillus-nomade · 26 avril

Pour ma part, je ne suis pas favorable au moteur de recherche sur les pages privatisées

Elle ne seront pas indexé car le moteur n'a pas accès au contenu faute d’être logué, c'est juste le code 302 renvoyé avec la redirection.
Pour faire propre, il faudrait sortir ces pages du sitemap ou depuis le fichier robots.txt Il n'y a rien de prévu dans le plugin pour cela. Mais tu peut te servir du plugin : https://github.com/gcyrillus/excludeSitemap que j'ai forké il y a quelques jours et qui permet aussi de filtrés les pages statiques individuellement.

Pour les autres modif que tu veut faire via les meta, je t'en laisse la responsabilité La page interdite est chargée avant que le navigateur soit redirigé. Certaines configuration dans les navigateurs peuvent tout simplement interdire ces redirections via les meta, d'ailleurs, il suffit d'appuyer sur la touche "escape" et la redirection via le meta n'est pas exécuté . Voilà en gros je ne suis pas fan de ces meta dans le cas de ce plugin. Cela reste un simple avis personnel et je me trompe peut-être, header(location: ..) ne vaut peut-être pas mieux mais la page interdite ne tombe pas dans le cache du navigateur.

En modifiant les scripts, prends soin de bien vérifier que $_SESSION['pageRequest']= $_SERVER['REQUEST_URI']; se fait au bon moment et correspond bien à la page privatisée demandée . Tu peut aussi gardé exit; ou die; aprés echo '<meta ...

Cdt

gcyrillus-nomade · 7 mai

@Paul
Pour revenir au cookie samesite, la prochaine version de Pluxml l'embarquera nativement : voir https://github.com/pluxml/PluXml/blob/master/core/lib/config.php voir la fonction : function plx_session_start() en modifiant en conséquence index.php avec plx_session_start(); voir https://github.com/pluxml/PluXml/blob/master/index.php

Pour sécuriser ton PluXml tu peut aussi voir ce post https://forum.pluxml.org/discussion/7312/optimisation-et-securisation-de-pluxml et suivre la procédure des plus simple.

Pour ton site en lien, je n'arrive pas à comprendre ce que tu as fait et comment tu peut ouvrir une page article protéger sans passer par la page de connexion exemple: http://trinitoust.bodieu.fr/article146/concert-cinema-de-josselin à moins que cet article ne soit pas protéger et que tu y a juste ajouté le message normalement inserer par le plugin.

Cordialement

gcyrillus-nomade · 24 mai

Bonsoir,
J'ai testé sur alwaysdata. Les redirections sont normales.

Par contre, j'ai fait une installation sans donnée chez IONOS.

Pluxml 5.8.9, sans plugins : Après authentification, le lien vers l'administration est normal
Pluxml avec uniquement le plugins vip-zone. Après authentification, l'anomalie de la redirection doublée apparaît
Pluxml en désactivant le plugins vip-zone , Après authentification, le lien vers l'administration redevient normal.

A suivre
Cordialement
Paul

Pour le coup, je ne vois pas ce qui perturbe ça chez IONOS . ajoutent-ils une session ou cookie aux visiteurs? et à quelle fins ? Ont-is mis en place un systeme de cache un peu trop optimisé? autre?
Cdt

Pb de redirection avec le plugin Vip-zone

Réponses

EDIT