LOGIN_PUBLIC et contenu à accès restreint

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

[1La 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

Aucune discussion

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