Précision préliminaire : avec Xprotector, il est bien question de la partie publique du site Web. Cela n’a donc aucun rapport avec les status "administrateur", "administrateur restreint" et "auteur" qui sont proposés par SPIP et concernent la partie privée du site Web.

Comment ça se passe pour le badaunaute ?

(badaud dans le sens flâneur...)

Le visiteur du site public clique sur un lien qui l’intéresse mais, ô surprise, ce texte se trouve en visibilité restreinte : il doit d’abord se faire reconnaître pour afficher les informations voulues.

Pour Xprotector, il existe des visiteurs identifiés par mot de passe et des badaunautes non identifiés. Les visiteurs identifiés sont ensuite attachés à un groupe d’utilisateurs auquel l’administrateur du site attribue des droits d’accès.

Chaque rubrique SPIP (ou sous-rubrique) peut être déclarée comme restreinte. Dans ce cas, elle n’est donc plus accessible au badaunaute. Il faut pour atteindre un de ses articles s’authentifier à l’aide d’un identifiant et d’un mot de passe.

Si la rubrique est autorisée pour le groupe d’utilisateurs auquel appartient le lecteur identifié, alors tout va bien. La page sera visible.

Si une rubrique ou une sous-rubrique n’est pas déclarée en accès limité dans Xprotector, elle est visible de tous.

Tant qu’un utilisateur n’essaye pas d’accéder à une zone restreinte, il ne lui est demandé aucune authentification.

En résumé...

 L’article 1 n’est visible que pour le lecteur identifié appartenant au groupe rouge car la rubrique de l’article 1 est restreinte au groupe rouge.
 L’article 2 est visible pour les lecteurs du groupe rouge ou du groupe bleu (rubrique restreinte à ces deux groupes)
 L’article 3 est limité au groupe bleu (rubrique restreinte au groupe bleu).
 L’article 4 n’est pas visible par le public car sa rubrique n’est autorisée à aucun groupe
 Les articles 5 et 6 sont visibles par tout public car ils sont dans une rubrique non restreinte
 les articles 7 à 9 ne sont pas encore publiés

La technique...

Xprotector crée ses propres tables mysql dans la base utilisée par SPIP. Il possède sa propre interface d’administration indépendante de celle de l’espace privée SPIP.

Il nécessite d’ajouter dans chaque fichier PHP du répertoire de base, une ligne faisant référence ou fichier
xprotect.php. Sont donc concernés : rubrique.php, article.php, sommaire.php, plan.php, breve.php... (à ne pas confondre avec les squelettes dont les fichiers possèdent des noms identiques mais avec pour extension .html).

L’installation et la mise en service de Xprotector sont très faciles, y compris sur des serveurs SPIP déjà en service. Il faut néanmoins prévoir un peu de temps pour retoucher l’oeuvre : la page d’identification est spartiate et l’interface en ligne comporte quelques fautes d’orthographe qu’il faut chasser.

Le fait de déclarer une rubrique en accès restreint ne concerne pas les sous-rubriques (mais, sur sourceforge.net, vous trouverez un patch pour Xprotector, qui vous aidera à limiter l’accès aux sous rubriques).

Il n’y a pas moyen non plus de prendre un "auteur SPIP" pour l’insérer dans un "groupe d’utilisateurs autorisés" même en recopiant les information directement dans la base mysql : l’encodage du mot de passe n’est pas identique. On ne peut donc éviter la double saisie des mots de passe.

Conclusion

Si on veut un espace "semi-public" simple à mettre en oeuvre sans remettre en question le choix SPIP, Xprotector est un très bon outil. Mais ça reste un outil d’appoint. Il ne propose, par exemple, aucun formulaire de demande d’identifiant. Le lecteur doit écrire au webmestre qui fait la saisie à la main de ce nouveau lecteur et lui attribue un groupe de droits.

Quelques liens pour aller plus loin avec Xprotector...
 http://spip-edu.edres74.net/article...
 http://www.metacites.net/article69.html

... et concernant la protection des rubriques par mots de passe
 http://www.spip-contrib.net/Comment...