Pluxml imbriqués : pb d'administrations non sécurisées
Bonjour Skyline et bonjour à tous,
tout d'abord, un grand coup de chapeau à l'auteur de ce "petit" cms.
C'est bien sûr un compliment quand on parle de Pluxml
. Bravo Skyline.
Pour en venir à mes moutons, je suis en train de créer un petit site de partage de photos utilisant les 2 versions de pluxml (cms et blog). Dans mon cas, le pluxml-cms sert de squelette à un site qui contient plusieurs pluxml-blog :
Pluxml-cms (le fichier index.php est à la racine de mon serveur)
|
+- pluxml-blog 1 (sous-répertoire du serveur contenant index.php du blog1)
|
+- pluxml-blog 2
|
+- pluxml-blog 3
Mon souci concerne la sécurité, et plus précisément l'accès à l'administration de pluxml.
Il semblerait en effet qu'il suffise d'être loggué dans l'un de ces pluxml, quelque soit sa hiérarchie dans ce squelette, pour avoir accès à TOUTES les administrations, y compris celle du pluxml principal.
(par exemple, une fois que l'admin de blog2 est loggué, il peut bien sûr accéder à l'administration de son blog, mais aussi à toutes les autres...
)
Ma question : Comment faire pour séparer complètement ces identifications ?
(J'utilise des .htaccess, mais j'aimerai connaître une solution plus "intégrée" à pluxml).
Peut-être que la prochaine documentation "Imbriquer plusieurs Pluxml" de la section bricolage m'aidera.
Si ce n'est pas le cas, merci d'avance pour vos lumières.
tout d'abord, un grand coup de chapeau à l'auteur de ce "petit" cms.
C'est bien sûr un compliment quand on parle de Pluxml
. Bravo Skyline.
et je dois dire que la version cms de pluxml me ravi au plus au point ! :PAntoine de Saint-Exupéry a écrit:Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.
Pour en venir à mes moutons, je suis en train de créer un petit site de partage de photos utilisant les 2 versions de pluxml (cms et blog). Dans mon cas, le pluxml-cms sert de squelette à un site qui contient plusieurs pluxml-blog :
Pluxml-cms (le fichier index.php est à la racine de mon serveur)
|
+- pluxml-blog 1 (sous-répertoire du serveur contenant index.php du blog1)
|
+- pluxml-blog 2
|
+- pluxml-blog 3
Mon souci concerne la sécurité, et plus précisément l'accès à l'administration de pluxml.
Il semblerait en effet qu'il suffise d'être loggué dans l'un de ces pluxml, quelque soit sa hiérarchie dans ce squelette, pour avoir accès à TOUTES les administrations, y compris celle du pluxml principal.
(par exemple, une fois que l'admin de blog2 est loggué, il peut bien sûr accéder à l'administration de son blog, mais aussi à toutes les autres...
)Ma question : Comment faire pour séparer complètement ces identifications ?
(J'utilise des .htaccess, mais j'aimerai connaître une solution plus "intégrée" à pluxml).
Peut-être que la prochaine documentation "Imbriquer plusieurs Pluxml" de la section bricolage m'aidera.
Si ce n'est pas le cas, merci d'avance pour vos lumières.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Effectivement c'est un petit souci que je n'ai jamais pris le temps de résoudre, promis ça sera corrigé dans la prochaine version.
Si tu veux bricoler toi-même tu n'as qu'à rajouter une variable dans la session qui précise quel pluxml on est autorisé à administrer.
Merci Skyline, ça marche impec'.
Bonne continuation.
PS : dans le sommaire de la Documentation Pluxml, Signature "intéractive" s'écrit sans accent
Juste un replys pour dire que je trouve très interressant la possibilité d'imbriquer plusieurs pluxml, mais que je n'ai aucune idée de comment ça marche, et je pense qu'on est pas mal dans ce cas (je n'en ai pas particulièrement besoin dans l'immédiat, mais ça me sera certainement utile un de ces 4
Bonsoir !
juste pour apporter une précision, mon installation de Pluxml imbriqués ne correspondra sans doute pas à tous les usages.
Dans mon cas en effet, les pluxml imbriqués forment un espace multi-utilisateurs et il n'y a donc pas d'administration commune par exemple (pour cela, il faudra certainement attendre la prochaine documentation de Skyline).
Pour rappel, un "bogue" permettait jusque-là à n'importe quel administrateur enregistré d'administrer tous les pluxml d'un même serveur.
Voici les modifications à effectuer pour éviter ces "effets de bord" (en gras, le code à ajouter/modifier) :
pour Pluxml et Pluxml-blog
=> fichier auth.php (l.15) :
if(md5($_POST) == $pwd[$_POST]){ # Si login et pwd concordent
$_SESSION = '1';
$_SESSION = $_POST;
$_SESSION = 'clef_admin_1'; # On définit la clef de cette administration
header('Location: index.php');
}else{
$msg = 'Mot de passe incorrect';
pour Pluxml
=> include.php (l.25) :
if (empty($_SESSION) or $_SESSION != 'clef_admin_1'){ # Si 'admin' de la session est vide ou si la clef ne correspond pas
header('Location: auth.php'); # Alors on va s'identifier
exit;
}
pour Pluxml-blog
=> prepend.php (l.27) :
if((empty($_SESSION) or $_SESSION != 'clef_admin_1') && @!$auth_page){ # Si 'admin' de la session est vide ou clef invalide
header('Location: auth.php'); # Alors on va s'identifier
exit;
}
Vous l'aurez compris, il suffit donc de remplacer clef_admin_1 par ce que vous voulez, du moment que cette clef est unique.
Cette méthode permet aussi de définir un admin principal (qui possède tous les droits), en rajoutant un or $_SESSION != 'clef_admin_principal' dans les fichiers concernés de tous les pluxml imbriqués.
A noter également que des restrictions pourront être faites dans les formulaires d'administration, afin de rendre impossible la modification des chemins des dossiers par les utilisateurs. Pour comprendre, jetez un oeil sur le paramètre "hidden" dans le fichier parametres.php.
Rappellez-vous que c'est du bidouillage, en attendant que Skyline introduise une telle sécurité dans sa prochaine version.
Pour ceux qui souhaitent créer une administration commune (dans le cas de Pluxml imbriqués mono-utilisateur), il faudra créer sur la page d'authentification principale un petit menu déroulant associant à chaque choix une clef.. mais je vous laisse bidouiller cela vous même :P.
Bon pluxml à tous !