Cette contrib vous permet de limiter la visibilité de plusieurs pages de votre site aux seules personnes identifiées, que ce soit par leur statut
- de visiteur
- de rédacteur
- d’administrateur.
Si un internaute accède à une page publique protégée, il sera invité à s’identifier par son login et son mot de passe. Une fois fait, s’il a le statut minimum requis, il accèdera directement à la page demandée.
Modifications requises
Les modifications requises sont mineures et peuvent facilement être appliquées à votre site.
Elles sont sans danger et peuvent tout aussi facilement être supprimées en tout temps.
Procédures
- Assurez-vous que vous n’avez pas déjà des fichiers portant les noms :
- rubrique_statut.html
- article_statut.html
- login_public.php3
- login_public.html
- rubrique_ok.php3
- article_ok.php3
- Téléchargez, décompressez et déposez à la racine de votre site les fichiers qui sont contenus dans ce document.
- Modifiez le fichier rubrique.php3 :
Changez la valeur de $fond :
//$fond = "rubrique";
$fond = "rubrique_statut";- Modifiez le fichier article.php3 :
Changez la valeur de $fond :
//$fond = "article";
$fond = "article_statut";- Créez un nouveau groupe de mots-clé appelé Accessibilité
- À la question Les mots-clés de ce groupe peuvent être associés, cochez pour cet exercice aux rubriques
[1]
- Créez dans ce groupe les mots-clés les mots :
- Administrateur
- Rédacteur
- Visiteur
Utilisation
Ajoutez le mot clé Administrateur, Rédacteur ou Visiteur pour limiter l’accès public d’une rubrique ou d’un article.
Explication
Prenons par exemple le cas d’une rubrique réservée :
le fichier rubrique.php3 n’appellera plus directement comme squelette le fichier rubrique.html mais plutôt le squelette contenu dans le fichier rubrique_statut.html.
Ce squelette n’affiche rien, il permet simplement de vérifier si la rubrique est limitée en accès public. Et si oui, de vérifier si l’internaute s’est identifié par son login et son mot de passe. Après, il vérifie s’il a le statut minimum requis. [2]
Une fois cette vérification faite, on affichera la rubrique telle que prévue par votre squelette rubrique.html
Les seuls fichiers vraiment nouveaux sont rubrique_statut.html :
<BOUCLE_accessibilite(MOTS){id_rubrique}{type=Accessibilité}>
<BOUCLE_a(RUBRIQUES){id_rubrique}{id_mot}{titre_mot=Administrateur}>
<?
if ($auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_rubrique}>
<?
}
else {
?>
<INCLURE(rubrique_ok.php3){id_rubrique}>
<?
}
?>
</BOUCLE_a>
<BOUCLE_b(RUBRIQUES){id_rubrique}{id_mot}{titre_mot=Rédacteur}>
<?
if ($auteur_session['statut']!='1comite'&& $auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_rubrique}>
<?
}
else {
?>
<INCLURE(rubrique_ok.php3){id_rubrique}>
<?
}
?>
</BOUCLE_b>
<BOUCLE_c(RUBRIQUES){id_rubrique}{id_mot}{titre_mot=Visiteur}{lang_select=non}>
<?
if ($auteur_session['statut']!='6forum'&&$auteur_session['statut']!='1comite'&& $auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_rubrique}>
<?
}
else {
?>
<INCLURE(rubrique_ok.php3){id_rubrique}>
<?
}
?>
</BOUCLE_c>
</BOUCLE_accessibilite>
<INCLURE(rubrique_ok.php3){id_rubrique}>
<//B_accessibilite>et
article_statut.html :
<BOUCLE_accessibilite(MOTS){id_article}{type=Accessibilité}>
<BOUCLE_a(ARTICLES){id_article}{id_mot}{titre_mot=Administrateur}>
<?
if ($auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_article}>
<?
}
else {
?>
<INCLURE(article_ok.php3){id_article}>
<?
}
?>
</BOUCLE_a>
<BOUCLE_b(ARTICLES){id_article}{id_mot}{titre_mot=Rédacteur}>
<?
if ($auteur_session['statut']!='1comite'&& $auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_article}>
<?
}
else {
?>
<INCLURE(article_ok.php3){id_article}>
<?
}
?>
</BOUCLE_b>
<BOUCLE_c(ARTICLES){id_article}{id_mot}{titre_mot=Visiteur}{lang_select=non}>
<?
if ($auteur_session['statut']!='6forum'&&$auteur_session['statut']!='1comite'&& $auteur_session['statut']!='0minirezo'){
?>
<INCLURE(login_public.php3){id_article}>
<?
}
else {
?>
<INCLURE(article_ok.php3){id_article}>
<?
}
?>
</BOUCLE_c>
</BOUCLE_accessibilite>
<INCLURE(article_ok.php3){id_article}>
<//B_accessibilite>Pour simplifier cette contrib, le fichier login_public.html est simplement le fichier login.html standard de SPIP où on a remplacé le formulaire privé (#LOGIN_PRIVE) en formulaire public (#LOGIN_PUBLIC). À la différence qu’une fois identifié, l’internaute ayant le statut minimum requis verra s’afficher la rubrique ou l’article demandé et non l’interface privée.
Nous avons également conservé, pour simplifier, les mêmes noms de fichiers pour ce qui est des fichiers rubrique_ok.php3, rubrique_ok.html et article_ok.php3, article_ok.html. Mais cela n’est pas recommandé, car on donne accès aux squelettes et nous ouvrons la porte à des chemins de contournements possibles.
Pour renforcer la sécurité, on doit changer les noms des deux fichiers rubrique_ok.php3 et article_ok.php3 pour des noms de votre choix et modifier les fichiers rubrique_statut.html et article_statut.html en conséquence.
On peut changer également les noms des fichiers rubrique_ok.html et article_ok.html et modifier en conséquence les fichiers rubrique_ok.php3 et article_ok.php3. Cela complique la vie aux intrus qui voudraient contourner la limitation d’accès.
Exemple
On ajoute simplement une extension numérique au hasard à notre fichier [3] :
- Changer le nom du fichier rubrique_ok.html ou rubrique_ok_5943.html
- Modifier le fichier rubrique_ok.php3 (ou l’équivalent selon le nom que vous lui aurez donné)
//$fond = ’rubrique_ok’ ;
$fond = ’rubrique_ok_5943’ ;
Il faut aussi se méfier des fichiers appelés par des INCLURE. Si on donne accès au squelette, on donne aussi le nom de ces fichiers. Et si on donne le nom d’une inclusion qui appelle une partie cachée de l’article, on donne ainsi la possibilité d’appeler directement cette inclusion.
Personnellement, j’utilise même une variable de session qui protège ces pages si elles ne sont pas appelées par rubrique.php3 et article.php3 ainsi que les fichiers appelés par INCLURE. Cela pourrait faire l’objet d’une autre contrib.
Modifications additionnelles
Cette contrib est une simplification d’une utilisation plus complexe que nous faisons sur plusieurs sites de l’accès limités à l’interface publique.
Sur plusieurs d’entres eux, les articles, les rubriques, les brèves et même les sites référencés portant un des mots-clés du groupe Accessibilité n’apparaissent dans aucun menu du site lorsqu’on a pas le statut requis. Une fois identifié, les divers menus s’enrichissent.
Cela permet d’éviter la frustration de se voir refuser l’accès à une page alors qu’on nous l’offre dans le menu ou le plan du site. [4]
Cela devrait faire l’objet d’une autre contrib.
Discussions par date d’activité
26 discussions
salut,
J’ai testé cette contrib mais rien à faire, ca ne marche pas comme ca devrait. Elle me permettrait pourtant de simplifier énormément mes problèmes actuels de restrictions. J’ai lu tous les commentaires et réactions pour tester et vérifier mais je ne vois toujours pas le problème.
La restriction a l’air de fonctionner puisque après ajout du mot clé l’article/rubrique ne s’affiche plus (erreur 404), mais par contre aucun profils ne peut plus la voir (pas même l’admin). J’ai vidé le cache, essayé sur une version toute neuve de la 1.8.3... rien a faire. je dois oublier un truc. Si on pouvais me dépanner ???
Tu ne devrais pas avoir d’erreur 404.
Normalement, tu devrais être orienté sur ta page de login plutôt (login_public.php3). Est-ce que tu as bien le duo login_public.php3/html ?
oui, ils sont présents et à priori corrects...
peut-être une piste, un bug qui n’apparait plus sur le dernier des spip utilisé pour tester ta contrib : impossible de trouver article_status ou rubrique_status...
je finis : mais ces deux fichiers sont bien sur presents dans le répertoire.
bixente
salut,
juste pour dire que tout marche nikel. Apparemment c’est la nuit ou le reboot qui ont fait « réapparaitre » le fichiers dans le répertoire ;-)
sous agora idem, juste a modifier la variable à tester. ’statut’ n’est plus utilisé dans la base, le champs est present mais il n’y a que mon compte qui est la valeur ominirezo. tous les autres sont null. en utilisant le champs ’profil’ tout roule.
merci pour ton aide
Répondre à ce message
Merci pour cette contrib que j’ai installe tres facilement et qui fonctionne tres bien...sauf que depuis, les traductions automatiques ne marchent plus...Quelqu’un aurait une explication et un remede ?
merci par avance
Puisqu’il y a plusieurs façons d’utiliser les traductions, on aurait besoin de plus de détails pour t’aider. Personnellement, je n’ai aucun problème de ce côté. Mes traductions d’articles sont dans les mêmes rubriques que leur version originale (aucun dédoublement de rubrique par langue ...) Et le tout fonctionne très bien. Toi ?
Les traductions marchent bien quand elles existent sous la forme d’un fichier par langue, mais c’est avec les tag multi que ca coince...
Merci
Je t’invite à m’écrire en privée si tu as toujours des problèmes de langue. Je pourrais peut-être t’aider...
Répondre à ce message
Merci pour cette contrib très simple à mettre en place. J’ai un probleme que personne ne semble avoir, c’est toujours une histoire de cache, quand je me deconnecte, j’ai toujours accès aux pages restreintes tant que je n’ai pas vidé le cache de mon navigateur. J’ai le meme probleme avec les autres contrib de gestion d’acccès restreints. J’ai réinstallé SPIP pour etre sure de ne pas avoir fait d’erreur.
Pour tester les sessions, j’affiche la valeur de $auteur_session[’statut’] et effectivement ça m’affiche toujours 6forum, meme déconnectée
Une idée ?
Je n’ai pas du tout ce comportement de mon côté. Je teste avec Explorer et Firefox... Dès que je change le mot clé sur un article, si je rafraichis simplement la page, mon droit d’accès change.
As-tu une adresse où je pourrais tester ce que tu dis ?
Répondre à ce message
Bonjour, et merci pour cette contribution qui est d’une simplicité logique presque déconcertante au regard des autres proposées.
Mon site est basé sur la version 1.8.3php.
Je pense avoir suivi toute la procedure
c’est à dire que :
_j’ai mis les 3 fichiers html dans le dossier squelette du spip
_j’ai mis les 3 fichiers php à la racine du spip (en changeant l’extension php3 en php, ce qui ne devrait pas avoir d’influence sur la suite)
_j’ai changé les fichiers rubrique.php et article.php pour qu’ils appellent respectivement rubrique_statut.html et article_statut.html
_j’ai créé mon groupe de mot clés Accessibilité et les mots clés indiqués.
_Enfin, j’ai selectionné Administrateur lors de l’edition de mon article test.
Mais je n’ai rien...
Quel que soit le statut minimum déterminé pour l’article ou la rubrique, la page est affichée sans problème.
Y-a-t-il une étape cachée pour faire fonctionner cette contribution ?
Je signale au passage sans vouloir être alarmiste que j’ai testé d’autres contributions incluant du php dans des boucles SPIP et qu’aucune d’elles n’a fonctionné.
Comment peut on vérifier que le php inclu dans article_statut.html est bien interprété ?
Merci d’avance pour vos réponses claires
Bon ! Premièrement, il n’y a aucun problème à mettre du php dans une boucle.
j’utilise se système sur tous mes sites depuis SPIP 1.7.2 à 1.8.3.
Questions
Si tu viens de modifier l’article ou la rubrique, tu es donc connecté comme administrateur. As-tu bien pensé à te déconnecter ? Sinon, c’est normal que tu puisses toujours voir la page.
Pour tester, tu peux travailler avec deux navigateurs : tu te connectes dans un (login et mot de passe ;-))mais pas dans l’autre. Tu fais tes modifications, par exemple dans Explorer et tu visualises la page dans Firefox.
Si ce n’est pas ça, tu peux m’écrire directement pour qu’on regarde plus en profondeur tes squelettes pour trouver le problème.
Bon, je ne sais pas d’où venait mon problème, j’ai réparé ma base de données, j’ai refais le squelette et ça marche.
Au passage, je signale que le logiciel windiff (téléchargable gratuitement) m’a bien aidé pour vérifier les différences entre mes deux dossiers squelette
(l’horrible ancien et le nouveau propre repris à zero)
je vous souhaite à tous plein d’excellence spipienne !
ps : je tente de développer un squelette conforme aux normes d’accessibilité (texte avant menus quand le style est déselectionné, navigation au clavier...) définis sur la-grange.net/accessibilite/
Je donnerais des nouvelles s’il fonctionne correctement.
Bonjour à tous,
je viens d’installer les fichiers sous SPIP1.8.3 et j’ai eu les mêmes soucis que Pactole.
Le problème vient des accentuations sur le groupe « Accessibilité » et le mot clef « Rédacteurs ».
Ma base est en UTF-8.
En supprimant les accents dans SPIP et sur les squelettes _public.html tout fonctionne apparement.
Je n’ai pas encore été au bout de l’utilisation du hack, mais je continu.
Merci pour ce travail !!!
françois.
Répondre à ce message
Bravo pour cette contrib’ !
Deux questions dessus :
1) Comment se déconnecter simplement (utile si on est sur une machine publique) sans passer par exemple par la partie privée du site ? Y a t il un script simple qu’on pourrait insérer ?
2) Comment les robots se comportent face à ce filtrage ? N’y a t il pas un risque qu’ils indexent les pages protégées, dont des extraits pourraient se retrouver sur les résultats des moteurs de recherche ?
Comment se déconnecter simplement ?
Tu peux ajouter simplement un lien sur ta page comme suit :
<a href="#URL_LOGOUT"><:deconnexion:></a>Sur nos sites, l’internaute n’e voit pas la totalité des pages dans le menu s’il n’est pas connecté puisque les pages protégés ne s’affichent que si la personne se connecte et que si elle a le statut requis. Ainsi, si tu vas dans une rubrique « X » dans laquelle il y a un article « A » non protégé, un article « B » protégé niveau rédacteur et un article « C », niveau visiteur... Si ton statut est visiteur mais que tu n’es pas identifié, tu ne verra dans le menu ou dans le plan du site que l’article « A ». Une fois identifié et la page rafraîchie, tu verra dans le menu l’article « A » et « C » mais pas l’article « B ». Un rédacteur identifié, lui, verra les trois apparaître.
Pour cette raison, nous offrons une boîte de connexion en PopUp qui permet de se connecter en tout temps ; ensuite de se déconnecter en tout temps.
Voir http://aide.iago.ca/rubrique.php3?id_rubrique=22
Pour ce qui est de robot, si un lien les mènent sur une page protégée, il tomberont comme n’importe qui sur la page de connexion et non sur l’article ou la rubrique elle même.
Si sur ton site tu conserves les fichiers backend, il faudra filtrer les résultats de tes boucles pour supprimer les pages protégées.
Merci pour ces réponses ;
Pour la déconnection, en fermant la fenêtre il me semble que ça ferme la session (si on a pas coché la case « rester identifier quelques jours » à l’identification) et donc l’identification. Est-ce vraiment fiable de faire ainsi ?
Pour le filtrage, que ce soit pour les menus ou les fichiers backend, tu en parles un peu dans les autres questions en disant que tu allais faire une contrib bientôt... En as tu dis plus ici ou ailleurs ?
Merci
Non ! je n’ai rien publié de nouveau. Je travaille actuellement sur une intrégration de cette contrib combinée à une gestion de groupe et à une gestion de profil d’utilisateur...
Ce qui utilise encore ce dont je parlais et beaucoup plus.
Je garde tout de même ce projet de contrib en réserve.
Répondre à ce message
Bonjour,
bravo pour cette contrib simple et efficace. J’ai un problème que personne ne rencontre apparemment sur le forum : après installation, lorsque je clique sur la rubrique protégée, j’ai une fenêtre d’identification avec ... 4 cartouches d’identification. C’est cocasse mais ça va plus loin puisqu’une fois les login/pword renseignés, la page qui vient après ... est aussi quadruple. J’en ai 4 qui se suivent, comme si une boucle avait été appliquée à l’affichage. C’est pareil dans irefox, Safari et Opera sous Mac OS X.
J’utilise un squelette Biospip v4. mais a priori il n’y est pour rien puisque les tests se situent à la racine du site sur les php3 qui ne sont pas dans le répertoire squelettes.
Quelqu’un a-t-il déjà rencontré ce problème ? Je précise : l’authentification sélective marche très bien.
Cordialement,
Fabinho
Si tu m’envoies un lien vers ton squelette, je pourrais peut-être t’aider.
J’ai exactement le même problème : affichage en quatre badeau répétés.
J’utilise beespip sur SPIP 1.82g sur hébergeur oneandone
Quelle est la solution ?
Merci
J’ai eu le même problème sur mon site.
Le problème se resout simplement !
Le mot clef Rédacteur sous entend Administrateur en même temps, et Visiteur regroupe Rédacteur et Administrateur.
Si vous mettez deux mots clef pour le même articles ou rubrique, une boucle imprévu se crée. On peut donc configurer le groupe de mot clef, avec un seul mot clef par article, on évite ainsi se problème d’affichage qui ralenti en plus le site !
Bonne journée à tous !
Dans la configuration de ce groupe de mots-clé, il faut cocher « On ne peut sélectionner qu’un seul mot-clé à la fois dans ce groupe. »
effectivement. Et avant, si ce n’est déjà fait, cocher « Utiliser la configuration avancée des groupes de mots-clés » dans la page ecrire/configuration.php3.
Aurai-je oublié de le signaler ?
Il ne faut jamais, en effet, mettre deux mots-clé de ce groupe sur un même article ou une même rubrique...
Répondre à ce message
Bravo d’abord pour cette contrib très pratique.
Sur un Spip standard pas de PB, ça marche parfaitement. Par contre j’ai eu quelques petits PBs en l’installant sur spip-eva : les rubriques auxquelles j’affecte le mot clé visiteur avec un affichage calendrier n’affichent aucun événement. (par contre aucun PB pour un affichage agenda)
D’autre part, lors de l’identification du visiteur tout se passe bien sauf qu’après avoir entré le password correct , un nouveau formulaire redemande le login. Il suffit alors de cliquer sur valider pour accéder à la page privée.
J’ai bataillé pour trouver une solutuion à ces deux problèmes , en vain...
Avez vous une idée de ce qui pose PB ?
Merci d’avance.
Malheureusement, je n’utilise pas Eva-Spip. Je ne peux donc t’aider sans voir tes squelettes.
Peut-être pourrais-tu m’en dire plus hors forum.
Si on trouve une solution, on viendra la donner alors ici...
Répondre à ce message
Bonjour,
Merci pour ce script qui marche parfaitement.
Cependant, sauf si je me trompe, le fait de protéger une rubrique ne protège pas de facto tous les articles de cette même rubrique. Est-il possible de la faire ou faut-il protéger tous les articles un par un ?
Merci d’avance,
Yves
J’ai hésité au début entre protéger une rubrique seulement, une rubrique et ses articles, une rubrique et toute sa branche. Sur les sites où j’utilise ce système, j’utilise aussi un filtre qui permet d’afficher dans l’ensemble des menus du site que les titres des articles et rubriques dont un internaute a les droits d’accès.
Il y aurait moyen de modifier le tout pour appliquer automatiquement le même niveau d’accès à l’ensemble de la rubrique ou même à toute sa branche.
Peut-être que je vais ajouter dans une prochaine version de cette contrib, cette option.
Pour le moment, pour une protection par branche, je combine la gestion des accès avec une variation personnelle du système de gestion de groupes.
Si tu va sur notre site d’Aide en ligne voir cette rubrique, tu verra qu’elle n’est pas vérouillée bien que sa rubrique mère l’est.
Je peux donc t’envoyer voir une section en plein coeur de rubriques réservées.
Mais ça, c’est une autre histoire...
Merci pour cette réponse...Je ne voyais pas la solution par ce chemin.
J’ai l’impression qu’on pourrait protéger facilement une rubrique et tous ses articles avec votre contribution en modifiant article_statut.html : on récupére par une boucle le numero de la rubrique où se trouve l’article, puis on fait le même contrôle que dans rubrique_statut.html
Je ne sais pas si je suis clair...
Il suffit de vérifier si l’internaute a le statut pour accéder à la rubrique de l’article au lieu de vérifier s’il a le statut pour accéder à l’article lui-même.
Tu peux le faire par un filtre ou une boucle tout simplement...
Répondre à ce message
Bonjour et merci pour ce travail.
Quelle astuce employer pour « créer » un log/pwd pour un visiteur.
Je ne souhaite pas créer meme un rédacteur car il pourrait avoir accès en rédaction sur le site, ce que je ne souhaite pas bien sur
Merci encore cordialement
eric
Si tu veux pouvoir créer un nouvel auteur et lui donner le statut de visiteur, il y a un drôle de comportement de Spip que tu dois savoir : il faut qu’il y ait au moins un auteur avec le statut de visiteur pour pouvoir créer des auteurs avec le statut de visiteur par l’interface privée !!! Ou, accepter les inscriptions en ligne. Et oui...
Donc, tu peux activer l’acceptation d’inscription des visiteurs en ligne sur ton site. Tu crées un visiteur. Tu otes l’acceptation. Et là tu pourras donner le statut de visiteur à un auteur et lui donner son login et mot de passe.
Ah ! l’ergonomie...
Merci Iago
CA fonctionne impec !!!
Malgré tout le visiteur peut acceder (certes de façon tres restreinte, il pourra juste envoyer un message ...) à l’interface privée si il tape http://monsite/ecrire/
comme ce projet n’est pour l’instant qu’un projet, cela va aller pour une demo.
Merci encore.
Si toutefois d’autres ont pu palier à cet acces je suis interesser de savoir comment ils ont pu proceder
Eric
Répondre à ce message
Cette méthode est claire, simple et fonctionne bien, merci.
Il me reste un point gênant. Dans le moteur de recherche, une recherche sur le mot clé « Visiteur » me renvoie la liste des articles limités aux visiteurs. Bien sûr ces articles ne sont lisibles que pour les visiteurs authentifiés, mais ce serait mieux de pouvoir éviter cette réponse. Y a-t-il un moyen de faire ignorer tout le groupe de mots clé Accessibilité au moteur de recherche ?
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
