LOGIN_PUBLIC et contenu à accès restreint

Publié le : 15 janvier 2005 – Dernière modification le 21 décembre 2021 – par Yorghos – 35 commentaires

1
2
3
4
5
9 votes

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Le principe de la présente contribution ne concerne que la méthode d’accès aux pages disponibles uniquement après authentification.

La gestion d’un espace à accès restreint, quel que soit le contenu, signifie que des informations propres à chaque visiteur peuvent être conservées dans les tables.
Par exemple, le contenu d’un espace personnel n’est accessible qu’après authentification [1].

Le principe de la présente contribution ne concerne que la méthode d’accès aux pages disponibles uniquement après authentification.

La page du login

Avant toute chose quelques rappels :
-  Pour activer les accès visiteurs et le #LOGIN_PUBLIC, il faut attribuer l’option forum sur abonnement à au moins un article (il peut s’agir d’un article non publié).

-  Faire le choix de l’inscription automatique des visiteurs ou supprimer la ligne dans le inc_formulaire.php3.

Sur la page d’accueil du site on crée un lien avec deux affichages :

<?
	if ($auteur_session) {
	print(" <a href=\"mon_espace.php3\" class=\"texte\">Mon
           espace priv&eacute;</a> ");
	}
	else {
	print ("<a href=\"loginpublic.php3\" class=\"texte\">vers
          l'espace r&eacute;serv&eacute;</a>");
		 }
 ?>

Le script détecte la présence d’un visiteur authentifié (if $auteur_session) et affiche “mon espace privé” avec un lien vers la page mon_espace.php3. Si le visiteur n’est pas connecté, l’affichage indique “vers l’espace réservé” et le lien pointe vers login_public.php3.

Sur cette page de login (login_public.php3), on peut imaginer de mettre à disposition, outre le formulaire d’authentification, une série de liens vers les pages qui ne sont accessibles qu’aux visiteurs authentifiés.

Authentification et visibilité des pages

Ces liens (s’ils existent sur la page login_public) sont toujours actifs, même si le visiteur n’est pas encore authentifié. Ceci signifie qu’en cliquant sur ces liens, on accède aux pages en accès restreint. Il faut avoir recours à un petit script placé dans l’en en-tête des squelettes qui protège l’accès :

<?  if (!$auteur_session['statut']) { 
print ("<h2>Cette partie est en accès restreint</h2>
<a href=\"login_public.php3\">Retour au formulaire</a>);
exit;
}
 ?>

De cette façon le contenu n’est plus accessible aux visiteurs non authentifiés. Je rappelle que l’exemple ci-dessus reprend la documentation de SPIP sur les formulaires et l’utilisation de la balise #LOGIN_PUBLIC.

Les informations disponibles après la connexion d’un visiteur :

-  

<?php echo $auteur_session['nom'] ?>

-> Nom
-  

<?php echo $auteur_session['email'] ?>

-> Email
-  

<?php echo $auteur_session['statut'] ?>

-> Statut

Précautions de sécurité

Dans le cas où l’on veut éviter que des contenus soient affichés par des visiteurs non-autorisés qui modifieraient manuellement les urls dans un squelette non protégé, en passant le paramètre id_article par exemple au squelette approprié, il faut penser à deux choses :

-  Préférer le classement de tous les articles à usage restreint dans des rubriques dont l’affichage est interdit sur le site public par exemple, id_rubrique !=XX dans la boucle RUBRIQUES (y compris sur les pages type mot ou recherche),
-  Créer un squelette article-XX, où XX est l’id_rubrique dont l’affichage est interdit et placer dans l’en-tête le script de test d’authentification présenté ci-dessus.

En conclusion, en utilisant les fonctions de SPIP et à l’aide de scripts php minimalistes, il est possible de mettre en place des règles d’accès de contenu faciles à gérer, avec le niveau de sécurité qu’offre SPIP.

Notes

[1] La mise en oeuvre d’un tel accès pourrait permettre de rajouter les “id_article” sélectionnés par le visiteur dans un champs extra de la fiche d’un auteur et de les convertir en liens vers les articles favoris dans l’espace personnel auquel accède l’auteur.

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

9 discussions

  • 10
    byld

    Cette contrib est fort interessante. Il y a t’il avec cette méthode, possibilité de récuperer l’id_auteur connecté pour afficher le critère {id_auteur=&id_auteur} ou quelque chose de ce genre pour l’inserer dans une boucle, n’étant pas un expert de php.
    En tout cas Bravo et merci, grace à cette contrib, je peux enfin créer la page perso des auteurs de mon site !

    • Yorghos

      Les possibilités de la 1.8 et l’utilisation du tableau $contexte_inclus ont rendus cette approche qui utilise le php directement dans le squelette dépassé. Tout est expliqué dans la contrib : http://www.spip-contrib.net/ecrire/articles.php3?id_article=909
      qui est toujours proposé à l’évaluation. Tous les fichiers et bouts de code nécessaires pour son fonctionnement sont disponibles dans le zip associé. Si jamais une explication manquait, je suis prêt à te fournir des détails complémentaires.

    • byld

      Je te remercie pour cette réponse rapide.
      Je suis en 1.7.2 et voilà plus d’une semaine que je cherche une solution.
      Mon site est un site d’ecrivains (78 en tout) et je veux fournir un espace privé (créé grace à cette contrib d’ailleurs) où j’affiche entre autre les textes les plus populaires de l’auteur en ligne sur son espace. J’ai utilisé ceci pour faire afficher son nom :

      <?php echo $auteur_session['nom'].'<br />';
switch ($auteur_session['statut']) 
{
        case '0minirezo' : echo 'administrateur<br />'.$REMOTE_ADDR; break;
        case '1comite'   : echo 'r&eacute;dacteur<br />'.$REMOTE_ADDR; break;
        case '6forum'    : echo 'simple visiteur'; break;
} ?>

      Mais c’est un petit code que j’ai récupéré dans le forum de SPIP et je ne peux connaitre l’id_auteur par ce biais.
      Je suis vraiment un débutant très mauvais en php et je pensais peut-être utiliser les mots clés mais puis-je récuperer le nom de l’auteur dans ce petit script et faire {id_mot=quelque chose} ? Ou cela revient au même ?
      Merci beaucoup pour ton aide que j’accepte volontiers.

    • Bernard Blazin

      Le lien que tu m’indiques est mort...

    • Yorghos

      Il faut imprimer par la commande print_r le contenu du tableau $auteur_session. Je ne suis pas certain que l’id_auteur en fasse partie. Mais le critère nom peut également servir dans la boucle auteur. Si on récupère $auteur_session[’nom’], ce nom sera utilisable dans une boucle AUTEURS avec le critère nom. Pour le lien mort je ne comprends pas, car c’est bien la bonne url. Peut-être faire in copier - coller dans le navigateur ?

    • Bernard Blazin

      Merci. Si je fais un print_r de &auteur_session j’obtiens bien la base spip_auteur et je vois l’id_auteur sous la forme [id_auteur]==>12 par exemple. Je vois en fait tout le contenu de la table.
      Maintenant le problème reste entier pour moi (je suis désolé d’être aussi mauvais). Comment récuperer cette ID pour l’inserer dans ma boucle Hit parade par exemple. Je ne comprends pas comment transformer mon critère {id_auteur} en {id_auteur=id de la table}
      Ou bien comment récuperer (en fait le petit bout de code php) $auteur_session[’nom’], pour utiliser la balise {nom}
      Pardonne moi si j’insiste lourdement mais je trouve ta contrib tout à fait exceptionnelle et très avant gardiste. Cela finaliserait celle ci en la proposant ainsi aux néophytes dont je fais partie. Encore merci pour ton aide passée et à venir..

    • Bernard Blazin

      Pardon en fait ma formulation est très mauvaise :
      Comment faire fonctionner cela :

       <BOUCLE_hitparade(ARTICLES){id_auteur=$auteur_session['id_auteur']}{par popularite}{inverse}{0,5}>
                    <div align="center"></div>
                    <li>
                      <div align="center"> #TITRE (popularité : #POPULARITE %)</div>
                    </li>
                    <div align="center">
                      </BOUCLE_hitparade>
    • Yorghos

      Justement il faut te servir des possibilités de la 1.8 pour transformer une variable en critère. Il existe différentes façons.
      -  En passant dans un inclure par $contexte_inclus la valeur de $GLOBALS[’auteur_session’][’nom’] et en le récupérant dans une boucle auteurs avec le critère nom.
      -  En passant le nom de l’auteur ou son id_auteur dans l’url (à condition qu’elle soit connue) puis en la récupérant dans les critère de boucle par la balise #ENVid_auteur

    • Bernard Blazin

      mInce ! je crois avoir oublié le fondamental ! Je suis en 1.7.2 et pas prêt de changer...Boudiou !!! ce doit être possible aussi .. ;o)

    • Yorghos

      Je ne sais plus, c’est un peu loin. Il est possible que la solution avec $contexte_inclus marche avec la 1.7. Sinon il faut utiliser du php dans le squelette. Mais en aucun cas les variables sous forme de critère. C’est peut-être l’occasion de se lancer et passer en 1.8.

    • Bernard Blazin

      LOL ! Impossible car trop de critères inventés et de choses peu naturelles déjà pour 1.7....Alors six mois de travail pour un 1.8 qui ne fera pas ce que je fais ? déjà voir

    Répondre à ce message

  • ola

    bonjour
    c’est la galère

    je suis en 1.7.2 et l’accès restreint à la rubrique voulue ne fonctionne pas dans l’espace publique
    pourtant « accès restreint » est bien présent pour cette rubrique dans l’espace privée

    quelqu’un pourrait il m’aider ?

    merci

    Répondre à ce message

  • 5
    Johan

    Bonjour,

    Je suis débutant en Spip et je désire créer un site à accès restreint.
    Pour sécuriser mes pages, j’ai rajouté dans mes squelettes :

    <?php  if ($auteur_session) {?>

    // Affichage de mon squelette

    <?php
} else {?>

    // Affichage du formulaire login_public

     ?>

    L’authentification fonctionne dans le cas normal mais si je met http://monsite/spip.php?auteur_session=true
    en URL, je peux accéder au sommaire de mon site. Même si je ne peux plus rien faire ensuite, je trouve cela plutôt embêtant.

    J’ai également testé en mettant if ($auteur_session[’statut’]) mais j’obtient le même résultat.

    Je précise que je n’ai pour l’instant sécurisé que les squelettes principaux (sommaire, article, rubrique, breve et 404).

    Est-ce que j’ai mal appliqué cette contrib ou est-ce une faille et si c’est le cas comment mettre en place la sécurisation des page à accès restreint ?

    Je vous remercie par avance pour l’aide que vous pourrez m’apporter.

    • Johan

      J’ai testé avec un squelette qui possède par défaut un accès restreint (EspFor 2.4) et j’arrive aussi à voir le sommaire en tapant http://monsite/spip.php?auteur_session=true (il faut parfois réactualiser pour que ca fonctionne).

      Il semblerait donc que le problème ne vienne pas de moi...

    • Bonjour,
      Ce système a été développé pour SPIP 1.8. Sur une version 1.9, il est préférable d’utiliser la balise SESSION qui marche très bien. Sinon, peut-être faire un squelette d’authentification distinct.

    • c’est du 50/50 :
      -  50 pour SPIP qui accepte de laisser php de définir la variable auteur_session
      -  50 pour la mauvaise configuration de votre php : register_globals est à on dans votre php.ini ce qui constitue une gros trou de sécurité.

    • bruno010

      Bonjour,

      Je suis également débutant sur spip. J’ai installé Spip 1.9.2c et je souhaite mettre en place un acces restreint pour une copropriété.

      Peux-tu m’expliquer exactement comment tu as résolu ton problème ?.

      Merci d’avance pour ton aide.

    • Que faut-il utiliser pour mettre en place un site à accès restreint, si cette méthode n’est pas fiable, sans utiliser de .htaccess.
      Le plugin SESSION n’étant pas fait pour cela.

    Répondre à ce message

  • Pierre

    Bonjour et bonne année 2008

    J’ai un petit problème avec le plugin accès restreint (Version : 0.2) :
    celui-ci fonctionne parfaitement sur les sites SPIP que je gère (1.9.2.b) sauf sur ceux qui utilisent une mutualisation du noyau. Dans ce cas, seul le premier site qui active ce plugin fonctionne normalement. Pour les autres, l’activation du plugin n’est pas possible :
    Dans gestion des plugins, une tentative d’activation renvoi une erreur « Accès interdit - activer_plugins ».

    Merci d’avance pour votre aide

    Répondre à ce message

  • Com-Unik

    Bonjour !

    Mon site était sous Spip1.9.1 et je l’ai mis à jour vers 1.9.2c

    Depuis, je ne peux plus ajouter les visiteurs à une zone, l’option ne s’affiche plus dans leur profil dans l’espace privé !!

    Y a-t-il une solution ?

    Répondre à ce message

  • WeB

    Une rubrique en accés restreint pour la zone publique et la zone privée... est accéssible à un administrateur restreint.

    Bug ou faille de sécurité, un administrateur restreint peut se rajouter a toutes les zones restreintes depuis son profil Auteur !

    « Ajouter toutes les zones » est visible en lien.

    Quelqu’un à une info SVP ?

    Merci

    Répondre à ce message

  • 5
    martinus

    Bonjour,

    Le principe qui consiste à tester en php la variable $auteur_session ne semble pas fonctionner toujours parfaitement à cause du cache du navigateur (à ne pas confondre avec le cache de SPIP).

    Si une page est demandée une première fois, sans identification, elle est stockée dans le cache du navigateur. Quand on y revient, avec la même URL, après identification, la version précédente est prise dans le cache du navigateur et affichée, et l’identification est sans effet apparent. Il faut appuyer sur CTRL+F5 pour voir le contenu conditionné par l’identification.

    J’ai fini par découvrir que le protocole HTTP prévoit un moyen de solutionner cela et que si on ajoutait au début des squelettes :

    #HTTP_HEADER{"Cache-Control: no-store, no-cache, must-revalidate, max-age=0"}
#HTTP_HEADER{"Pragma: no-cache"}
#HTTP_HEADER{"Expires: Mon, 26 Jul 1997 05:00:00 GMT"}

    Avec Mozilla FireFox 1 ou 2, notamment, cela fait disparaître tout problème.
    Tout n’est d’ailleurs peut être pas nécessaire pour ce navigateur, peu importe.

    Mais avec MS - Internet Explorer 6 ou 7, cela ne marche pas toujours. Il faut généralement appuyer sur CTRL+F5 pour voir le bon contenu. Je répète, le cache de SPIP n’est pas en cause et un recalcul de la page ne suffit pas toujours.

    Si on paramètre IE de manière à ce qu’il « vérifie s’il existe une version plus récente des pages enregistrées à chaque visite de page », le problème disparait aussi.

    Mes visiteurs sont souvent peu expérimentés, sont équipés à 99% d’IE, et cela leur parait très difficile de changer ce paramètrage, et bien sûr incroyablement complexe d’installer FireFox. Ils trouvent plus simple de dire « ça ne marche pas ». De toutes façons je ne trouve pas correct d’imposer à mes visiteurs un paramétrage ou un navigateur.

    Ce qui est étrange, c’est que le souci ne semble pas être souvent remonté et que la documentation ne mentionne même pas la nécessité des headers cache-control etc... Pour ma part je n’avais pas remarqué ce problème quand j’étais en 1.8 (mais ça prouve rien) et sur mon serveur de développement (Apache/Windows) je ne le rencontre pas non plus.

    Cela pourrait-il être indirectement lié à la dernière version de SPIP ou encore dépendre de l’hébergeur (OVH en l’espèce) ?

    Je sèche et mes utilisateurs ont du mal...

    Est-ce que certains n’ont jamais rencontré ce souci ?
    Vos retours d’expérience seraient précieux pour essayer d’avancer !

    Merci.

    Martin

    • Yorghos

      De mon côté chez OVH, avec une version 1.8, le fonctionnement dans un INCLURE avec le cache réglé à 1*1, je n’ai pas de difficulté. Par contre il y a un bug avec l’#URL_LOGOUT que je n’ai jamais résolu.

    • martinus

      Ok, merci.

      Je suis en 1.9.1 et je ne mets pas le cache à une aussi faible valeur, et ne voudrais pas être obligé de le faire.

      Le code php est présent dans le cache et exécuté à chaque fois, me semble-t-il.

      A suivre...

    • bruno

      je suis sur ovh spip version 1.9.1

      Meme avec cache0 j’ai le même pb

      Y-a-t-il une solution ?

    • cedric

      J’ai le meme probleme avec spip 1.9.1.

      Lorsque je me connecte (login/mot de passe) tout va bien, mais si je me déconnecte et me reconnecte alors rien ne va plus. Il cree une url bizare et refuse que je me connecte.

      J’a iessayé plein de trucs, je suis désespéré car c’est une grande faille...

      des idées nouvelles ?

      merci !

    • Bonjour,

      Je crois que ton problème est tout à fait différent du mien et n’a rien à voir avec le cache.

      Si tu te déconnectes avec [(#URL_LOGOUT)] avec une page de retour dont l’URL contient plus d’un paramètre, donc le signe ampersand, celui-ci n’est pas codé et retransmis correctement et la page de retour n’est pas trouvée après deconnexion.

      C’est un bug déja signalé, mais je n’ai pas vu, ni trouvé, le correctif. Tu peux cependant le contourner en spécifiant une page de retour avec 1 paramètre, la page d’accueil par exemple, en écrivant [(#URL_LOGOUT{spip.php?page=sommaire})]

      Cordialement,

      Martinus

    Répondre à ce message

  • 1
    llenne

    Voici une méthode pour restreindre l’accès aux données créées par l’auteur
    (testé avec SPIP 1.9.1)

    L’auteur s’est au préalable connecté à l’aide de la balise
    #LOGIN_PUBLIC

    Création d’un critère dans mes_fonctions.php (à la racine du site)

    le critère : {session_id_auteur}

    dans le squelette :

    <BOUCLE_mes_rubriques(RUBRIQUES) {racine} {session_id_auteur}>
   #TITRE
</BOUCLE_mes_rubriques>

    dans le fichier mes_fonctions.php :

    function critere_session_id_auteur_dist($idb, &$boucles) {
	
	// Pour quel auteur connecté
	global $session_auteur;
	if (!$session_auteur) {$this_session_auteur = "invisible"; }else{$this_session_auteur = $session_auteur['id_auteur']; }
	
	// Application du critère 
	$boucle = &$boucles[$idb];
		// Filtre les données de l'auteur connecté
			$boucle->where[]= "id_auteur = '".$this_session_auteur ."'";

}

    Et voilà comment faire un critère suplémentaire sur les boucles.

    Ludovic LENNE (ludovic[@]lenne.org)

    • llenne

      Petite correction dans le code de la fonction :

      function critere_session_id_auteur_dist($idb, &$boucles) {
	
	// Pour quel auteur connecté
	global $session_auteur;
	if (!$session_auteur) {$this_session_auteur = "invisible"; }else{$this_session_auteur = $session_auteur['id_auteur']; }
	
	// Application du critère 
	$boucle = &$boucles[$idb];
		// Table de l'objet
			$boucle->where[]= "'id_auteur = \'".$this_session_auteur.\''";

}

      le filtre (id_auteur = ...) doit être entouré par des guillemets simple (penser à echapper ceux du filtre : ’ id_auteur = \’...\’)

      Ludovic LENNE (ludovic[@]lene.org)

    Répondre à ce message

  • 5
    Yorghos

    Mon retour d’expérience et la contribution gestion hierarchique des accès restreints peuvent se cumuler. D’après ma propre expérience, il n’est pas conseillé de rendre les rubriques inaccessibles, car ceci influence le référencement. Il est tout à fait possible avec le #LOGIN_PUBLIC de gérer une page rubrique qui affiche les titres des articles, éventuellement les descriptifs et ne pas autoriser l’accès à l’article complet. C’est ce que je fait sur mon site pour toute les rubriques indiquées en page d’accueil par un cadenas.

    • AM

      Je cherche à créer une partie restreinte pour mon site et votre solution m’intéresse. Serait-il possible de mettre le lien de votre site pour exemple ?

      D’avance merci.

    • Sur la page d’accueil http://ww.avernes.fr/Oncologie il suffit de choisir une rubrique indiquée par un cadenas. La page rubrique affiche les sommaires, mais les articles ne peuvent s’afficher en entier.
      @+
      YR

    • AM

      Merci,

      Je suis aller faire un petit tours et c’est intéressant.

      Cependant mon niveau (débutant) dans spip ne me permet pas de me lancer comme ça
       :-(

      J’ai trouvé une solution... plus facile pour moi : SitenKit.

      Je peux restreindre l’accès à une rubrique sans depuis l’interface administrateur.

    • j’aimerais realiser la meme chose mais n’autoriser l’accé qu’aux admins du site,
      c’est possible ?

    • Le principe est rigoureusement le même. La solution passe par $auteur_session[’statut’], dont on teste la valeur, si elle vaut 0minirezo, il s’agit d’administrateur. Je suis entrain de réfléchir sur une nouvelle contrib, exploitant les possibilités de la 1.8. Pour un début de piste voir mon message vers 19h40.

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom