Le plugin accés restreint par groupes - SPIP - contrib

Transcription

1 sur 38
http://www.spip-contrib.net/Le-plugin-acces-restreint-par#forum390163
Le plugin accés restreint par groupes
dimanche 22 octobre 2006, par Coyote, cy_altern. Dernier ajout samedi 30 décembre 2006
le plugin accés par groupes permet de restreindre l’accès à des rubriques et leurs
contenus en gérant des groupes d’utilisateurs autorisés. A la différence du plugin
"accés restreint", le filtrage est appliqué aussi bien dans l’espace privé que l’espace
public.
Ce plugin reprend la contrib http://www.spip-contrib.net/spip.ph...
[http://www.spip-contrib.net/spip.php?action=redirect&id_article=1039] (version
0.7 réservée aux versions 1.8 de spip) dont il constitue la version 1.0. Ce plugin est
compatible avec les versions 1.9.0 et 1.9.1 de spip. Il n’est pas compatible avec la
version SVN spip 1.9.2.
1.9.2
[Mises à jour]
la version [1.0.1] remplace la version 1.0 pour permettre d’assurer le filtrage des
articles en mode "révision". Voir ce forum [#forum388848] pour plus de détails.
Il est vivement conseillé de procéder à la mise à niveau des plugins v1.0, la mise à
jour des fichiers n’entraînera pas de modification de vos groupes et restrictions
existant.
passage à la version [1.0.2] qui permet l’utilisation du critère tout_voir et du filtre
accesgroupes_visualise pour permettre l’affichage d’une liste de toutes les
rubriques/articles/brèves y compris les restreintes.
Voir en ligne : Un tutoriel pour la prise en main du plugin accès par groupes
[http://p7app.geneve.ch:8007/spip/article.php3?id_article=288 ]
[plugins incompatibles]
acces restreint
barre typo enrichie (en revanche le plugin barre typo écologique est compatible)
0. But :
Un des besoins fréquent lorsque l’on gère un site sous SPIP est de pouvoir
restreindre l’accès à des rubriques afin qu’elles ne soient accessible qu’à certains
utilisateurs. De façon complémentaire, pour permettre une gestion de ces accès
restreints complète, simple et ergonomique, il s’avère indispensable que les
utilisateurs "autorisés" soient gérés par groupes.
groupes
Cette contrib répond à ce besoin en essayant d’offrir le maximum de possibilités
tant dans la gestion des utilisateurs autorisés que dans les restrictions d’accès, le
tout sans avoir à intervenir sur les squelettes utilisés.
Pour permettre de réaliser des contenus totalement protégés, les restrictions
d’accès doivent pouvoir s’appliquer aussi bien à l’espace privé qu’à l’espace public.
06/01/2007 22:05
2 sur 38
Pour les utilisateurs de la contrib (v0.7 ou v0.61), les nouveautés de cette version
1.0 (plugin) sont signalées par un : [v1.0]
1. Ce plugin permet :
de créer des groupes d’auteurs : ces groupes peuvent êtres constitués
d’utilisateurs , d’autres
autres groupes (sous-groupes) ou de statuts (c’est à dire que
tous les utilisateurs d’un statut donné appartiennent à ce groupe). Cette
organisation génère elle-même d’autres contraintes techniques à gérer : ainsi il
ne doit pas être possible d’inclure le groupe "pére" dans le groupe "fils" si celui-ci
contient déja "fils" (sinon on risque la boucle infinie lors de la routine de contrôle
d’accès).
de limiter l’accès à certaines rubriques "rubriques
rubriques restreintes " aux groupes créés :
cette limitation d’accès peut s’appliquer soit dans la partie publique ET dans la
partie privée , soit à l’une OU l’autre de ces parties séparément.
Les rubriques "à
à accès restreint " sont gérées automatiquement : dès qu’au moins
un groupe contrôle une rubrique, cette dernière devient alors à "accès
accès restreint " et
elle est inaccessible pour les lecteurs n’appartenant pas à ce groupe. Inversement,
si aucun groupe ne "contrôle" une rubrique, elle est accessible par tous les
internautes.
Le fonctionnement du système de restriction d’accès est conçu de manière à ce que
toutes les sous-rubriques d’une rubrique à accès restreint soient elles aussi
restreintes : principe "d’héritage
d’héritage des restrictions ".
[v1.0] Ce plugin permet également qu’un admin général puisse créer des groupes
en ayant la possibilité d’en "déléguer
déléguer"
déléguer ensuite la gestion à un admin restreint, ce qui
correspond à une sorte de "changement de propriétaire" d’un groupe.
2. Un exemple de situation à gérer :
Pour mieux cerner le fonctionnement, voici le cahier des charges auquel cette
contrib tente de répondre :
un SPIP est installé sur le site d’un établissement scolaire (disons un lycée) pour
permettre la publication de contenus élaborés par les profs et/ou les élèves.
Ce SPIP comprend une rubrique par discipline (Anglais, Lettres, SVT...), tous les
profs d’une discipline sont administrateurs
dministrateurs de la rubrique de leur discipline afin
qu’il puissent gérer/modérer les publications des élèves dans celle-ci. Tous les
élèves sont rédacteurs dans ce SPIP, les parents peuvent avoir un compte visiteur.
visiteur
On souhaite que les profs d’une discipline puissent, s’ils le veulent, créer des
sous-rubriques à accès réservé selon leurs besoins. Par exemple une
sous-rubrique "travail en cours" dans laquelle ils pourront mettre au point
ensemble les sujets de leurs prochains devoirs ou les corrections de ceux-ci. Il
06/01/2007 22:05
3 sur 38
semble évident qu’il ne faut PAS que les élèves (comptes auteurs) aient un accès à
cette sous-rubrique que ce soit dans la partie publique ou la partie privée !
On veut également qu’il soit possible d’avoir des rubriques à accès réservé
uniquement aux profs (comptes admins restreints) pour qu’ils puissent publier
des infos qui ne concernent pas les élèves (documents administratif,
comptes-rendus de réunions syndicales, préparation de projets
pluridisciplinaires...).
Il doit également être possible d’avoir des rubriques dans lesquelles les profs
peuvent préparer des documents (par exemple les comptes-rendus des conseils
de classe) qui seront accessibles une fois publiés (donc accès non-restreint dans
la partie publique ) mais confidentiels tant qu’ils sont en mode "en cours de
rédaction" ou "proposé à l’évaluation" (donc accès restreint dans la partie privée ).
Il faudra aussi une rubrique dont l’accès est réservé à tous les utilisateurs inscrits
dans l’établissement (profs = admins restreints + élèves = auteurs + parents =
visiteurs) dans laquelle on mettra, par exemple, les emplois du temps qui ne
seront donc pas visibles par les "extérieurs" à l’établissement.
Enfin, il doit également être possible de créer des rubriques réservées :
aux élèves d’une classe (un groupe "classe"),
à plusieurs élèves et quelques profs, par ex le groupe "club informatique"
aux profs de 2 ou 3 disciplines (par ex" profs de sciences", cad les profs de SVT
+ Physique/Chimie + Maths). On obtient donc un groupe de groupes
...
l’administrateur général du spip doit également pouvoir créer des groupes dont il
déléguera ensuite la gestion aux admins de rubriques
avec comme circonstance aggravante que les admins généraux doient pouvoir
"s’inviter" dans n’importe quel groupe pour consulter le contenu des rubriques à
accès réservé.
3. Installation du plugin acces groupes :
[v1.0] Comme tous les plugins : récupérez le dernier zip à jour de cette contrib sur
http://zone.spip.org/files/spip-zone/ [http://zone.spip.org/files/spip-zone/] ou
sur le miroir http://miroirspip.ventre.name/build...
[http://miroirspip.ventre.name/builds/spip-zone/], décompactez le et placez le
dossier "acces_groupes
acces_groupes " obtenu dans votre répertoire /plugins (à créer à la racine
de votre spip si nécessaire), rendez vous sur l’interface de gestion des plugins
(menu Configuration > Gestion des plugins ), cochez le plugin "acces_groupes
acces_groupes " et
validez.
Vous devriez voir apparaître une icone supplémentaire
dans le menu "auteur
auteur"
auteur pour les administrateurs (de
rubriques et généraux) (merci à Litteul Kevin pour son
icone nettement plus "classe" que mes pauvres
06/01/2007 22:05
4 sur 38
bidouillages...)
Du point de vue de la base de données, ce plugin installe 3 tables supplémentaires :
spip_accesgroupes_auteurs , spip_accesgroupes_acces et
spip_accesgroupes_groupes , sachant que grâce au nouveau système de gestion des
requètes MySQL par le core de spip 1.9 ("SPIP est grand et ses codeurs sont mes
prophètes !"), le préfixe ’spip
spip’
spip sera automatiquement remplacé par le préfixe des
tables que vous avez défini dans votre fichier /ecrire/mes_options.php (variable
$table_prefix ) si vous gérez plusieurs spip avec une seule base de données.
ATTENTION !!!
ce plugin n’est PAS compatible avec le plugin "acces
acces restreint " puisqu’il surcharge
les mêmes fonctions que lui pour le filtrage des BOUCLES (affichage de l’espace
public) : si celui-ci est actif, vous devez d’ABORD le désactiver (la vérification n’est
pas gérée par le plugin) !!!
Si vous procédez à une mise à jour depuis une version antérieure dans le cas ou
votre spip serait passé de la version 1.8 (où vous utilisiez la version 0.7 ou 0.61
de la contrib originale) à la 1.9, vous devez d’ABORD procéder à la mise à jour des
tables utilisées. Pour cela connectez vous sur le script
/plugins/acces_groupes/maj_tables.php qui permet de "patcher" les tables à
partir de celles de la version 0.7 ou 0.61. Ce script est extrèmement sommaire [1]
et vous demandera de saisir les paramètres de connexion à votre base de données
MySQL pour éviter que n’importe qui puisse le lancer. Une fois ce script joué, vous
pouvez effacer le fichier maj_tables.php .
4. Fonctionnement obtenu lorsque l’on intègre ce plugin :
pour un internaute qui n’est pas authentifié toutes les rubriques restreintes (ce
qui inclus les sous rubriques, les articles, les brèves, les liens ...) seront [v1.0]
invisibles à ce visiteur dans la partie publique.
pour un visiteur authentifié, seules les rubriques restreintes auxquelles il n’a
pas accès (via son appartenance à un groupe ou son statut) seront invisibles.
pour les auteurs authentifié : idem les visiteurs pour la partie publique, en
revanche pour la partie privée, les
rubriques à accès restreint sont
(pour l’instant !) visibles mais non
accessibles.
pour les administrateurs de rubriques ("admin restreint") : idem les auteurs
SAUF pour les rubriques dont ils sont administrateurs . Pour ces rubriques, ils ont
un accès dans la partie publique et la partie privée MEME s’ils n’appartiennent pas
à un groupe autorisé à l’accès. Il paraissait en effet logique qu’un admin de
rubrique ait forcément accès aux rubriques dont il à la gestion. Il peut également
créer des groupes (ou utiliser des groupes existants) pour limiter l’accès aux
rubriques qu’il administre et à leurs sous-rubriques. Il ne peut modifier que les
06/01/2007 22:05
5 sur 38
groupes et sous-groupes qu’il a créé (= dont il est le "propriétaire
propriétaire ").
pour les administrateurs généraux ("admin général"), idem les auteurs mais ils
peuvent accéder au gestionnaire de groupes pour modifier n’importe quel groupe
et donc s’ajouter aux utilisateurs autorisés. Un admin général peut ainsi
visiter/modérer une rubrique à accès restreint MAIS il deviendra alors visible dans
la liste des utilisateurs autorisés, ce qui permet au "propriétaire" d’une rubrique
restreinte (admin restreint) de savoir que l’admin général s’est "invité" dans sa
rubrique.
Concernant l’intégration des statuts dans un groupe :
l’idée est la suivante : TOUS les
utilisateurs du statut sélectionné
sont membres du groupe. Cela
implique qu’ils ont donc TOUS
accès aux rubriques réservés à ce
groupe.
Par exemple si un admin choisit de faire un groupe "tous les admins restreints"
dans lequel il intègre le statut "Administrateurs
Administrateurs " et qu’il donne l’accès à ce groupe
pour la rubrique "le coin des admins", on aura comme résultat que tous les admins
du SPIP (restreints ou généraux) peuvent accéder à cette rubrique mais que ni les
visiteurs ni les auteurs ne pourront la visiter. Mais si l’administrateur le souhaite, il
peut également intégrer l’auteur Toto dans ce groupe afin de lui permettre
d’accéder aussi à cette rubrique.
5. L’interface de gestion des groupes et des rubriques
restreintes :
06/01/2007 22:05
6 sur 38
Pour rendre les chose plus faciles à apréhender (l’imbrication
groupes/sous-groupe peut devenir complexe, les restrictions des rubriques
multiples...), l’interface de gestion des groupes (exec=accesgroupes_admin
exec=accesgroupes_admin )
intègre :
l’affichage de la liste des groupes et des rubriques qu’ils contrôlent
l’arborescence des groupes/sous-groupes.
Chaque rubrique à accès restreint
peut être configurée pour que la
restriction porte soit sur la partie
privée,
privée soit sur la partie publique ,
soit sur les 2 (privé + public) . Il est
possible (pour un admin général ou pour un admin de rubrique dans une rubrique
qu’il administre) de configurer une restriction d’accès sur une sous-rubrique
d’une rubrique elle-même déja restreinte. Néanmoins, le principe "d’héritage
d’héritage des
restrictions " d’une rubrique sur ses sous-rubriques impose les règles suivantes :
rubrique parent restreinte "privé + public" => sous-rubrique restreinte
obligatoirement "privé + public"
rubrique parent restreinte "privé" uniquement => sous-rubrique restreinte
"privé" ou "privé + public"
rubrique parent restreinte "public" uniquement => sous-rubrique restreinte
"public" ou "privé + public"
Les administrateurs de rubriques ne peuvent modifier QUE les
groupes qu’ils ont eux-même créés (= propriétaires). Cela
permet de rester cohérent avec le fonctionnement de
06/01/2007 22:05
7 sur 38
l’administration des rubriques : ils ne peuvent interdire l’accès qu’a l’intérieur de
leurs rubriques. Ils peuvent utiliser des groupes créés par d’autres admins mais
ne peuvent les modifier .
[v1.0] Pour simplifier la vie des admins de rubriques, un
admin général peut créer un groupe, lui attribuer des
rubriques en accès restreint puis transférer la "propriété" de ce
groupe à un admin de rubrique : celui-ci pourra alors gérer ce
groupe comme s’il l’avait créé lui même.
Chaque groupe peut être configuré pour
permettre aux utilisateurs n’ayant pas le
droit d’accès à une rubrique d’envoyer un
message au propriétaire du groupe
demandant leur intégration dans celui-ci.
Cette situation va se rencontrer
principalement dans l’espace privé (les
rubriques restreintes étant visibles dans
les listes de rubriques/sous-rubriques) mais également dans
l’espace public pour un utilisateur qui suivrait un lien vers une
rubrique protégée (si le squelette le prévoit, cf "Type de
filtrage et squelette" ci-dessous). Ce paramètre permet
Configurer la
d’afficher un
possibilité d’une
formulaire de
demande
demande
d’intégration au
d’inscription
groupe
dans le groupe
lorsque l’utilisateur ne peut accéder
à une rubrique. Ce message sera
consultable par le propriétaire du groupe (si c’est un admin de rubrique) ou par
n’importe quel admin général (si le groupe est créé par un admin général) dans la
messagerie de l’interface privée, il comporte un lien direct vers l’interface de
gestion du groupe concerné. Les auteurs en attente d’intégration sont listés dans
cette interface et peuvent être intégrés
ou rejetés en un clic.
[v1.0] Lorsque le propriétaire du
groupe aura rejeté ou accepté la
demande d’inscription de l’auteur, le
message de demande sera
automatiquement effacé .
6. Type de filtrage et squelette :
[v1.0] Etant donné que ce plugin filtre directement les BOUCLES qui génèrent le
contenu de l’espace public rendant invisibles celles qui sont restreintes pour un
utilisateur non-authentifié , vous avez le choix entre 2 types de filtrages :
06/01/2007 22:05
8 sur 38
Un filtrage fort : pas d’indication qu’un contenu existe mais qu’il n’est pas
accessible (page 404 si un utilisateur non-autorisé essaye d’accéder directement
au contenu d’une rubrique restreinte, par ex en suivant un lien ou un signet de
son bookmark). Si vous ne souhaitez pas modifier votre squelette, c’est cette
solution qui sera retenue par défaut.
Pour rendre les choses plus ergonomiques, vous devriez donc avoir un lien
’S’identifier
S’identifier ’ générique sur tout le site, qui permet aux personnes habilitées de se
connecter pour accéder au contenu. Pour cela utilisez par exemple la balise
#LOGIN_PUBLIC (cf cet article de spip-contrib
[http://www.spip-contrib.net/Les-multiples-possibilites-du] pour plus d’infos).
Un filtrage avec information :
si l’internaute essaye
d’accéder au contenu d’une
rubrique restreinte alors il se
retrouve sur une page
l’informant qu’il est nécessaire
de s’identifier pour accéder au
contenu. Si une fois connecté
il ne fait pas partie des
utilisateurs autorisés, alors il
aura éventuellement le
formulaire de demande d’intégration au groupe (selon la config du groupe, cf
paragraphe précédent). Pour obtenir ce fonctionnement vous disposez des filtres
"accesgroupes_article_restreint
accesgroupes_article_restreint ", "accesgroupes_rubrique_restreinte
accesgroupes_rubrique_restreinte " et
"accesgroupes_breve_restreinte
accesgroupes_breve_restreinte " qui vous permettent d’intégrer dans vos
squelettes des pages "article.html
article.html ", "rubrique.html
rubrique.html " ou "breve.html
breve.html"
breve.html le formulaire
de #LOGIN_PUBLIC (si l’utilisateur n’est pas connecté) ou (selon config) le
formulaire de demande d’accés.
Pour réaliser cette intégration dans ces pages, il vous suffit de rajouter aux
BOUCLES principales de ces pages le code suivant (exemple pour la page
article.html) :
06/01/2007 22:05
9 sur 38

</BOUCLE_article_principal>

[(#ID_ARTICLE|accesgroupes_article_restreint|?{'
',''})<INCLURE{fond=inc_accesgroupes_login}{skel=#CHEMIN{inc_acces
<//B_article_principal>
Comme le montre le code ci-dessus, vous ajoutez donc à la
BOUCLE_article_principal (celle qui englobe TOUTE la page) une condition en cas de
retour vide (cad en principe affichage de la page 404 : "page non trouvée") qui
permet d’INCLURE le fichier inc_accesgroupes_login.html (situé à la racine du
répertoire /plugins/acces_groupes ) dans le cas où l’absence de page est due à une
restriction d’accès et non pas à une page vraiment absente.
La page inc_accesgroupes_login.html livrée avec le plugin est (volontairement)
dépouillée, ce qui vous laisse la possibilité de la "customiser" selon vos goûts et
votre charte graphique.
7. Fonctionnement du plugin :
Les filtrages des parties publiques et privée reposent sur 2 principes différents
(pour l(instant !) :
Pour la partie privée , peu de modifications par rapport aux versions précédentes
de cette contrib : on vérifie dans les pages de gestion des articles (exec=articles
et exec=articles_edit) , rubriques (exec=naviguer et exec=rubriques_edit) et
breves (exec=breves_voir et exec=breves_edit) si l’élément dont on affiche la
page id_article=xxx par ex) fait partie d’une rubrique à accès restreint (en
fonction de l’id_auteur et de son appartenance aux groupes/statuts) et si c’est le
cas on envoie le message de restriction d’accès : jusque là rien de bien
compliqué...
[v1.0] Pour la partie publique les choses se compliquent puisqu’il faut gérer le
cache...
cache Et pour "rendre à César ce qui appartient à César" il me faut ici remercier
Cedric Morin pour son système de filtrage mis au point pour le plugin "accès
accès
retreint"
retreint qui permet de surcharger directement les requêtes SQL des BOUCLES de
spip. Cela permet donc d’exclure des résultats renvoyés par la base de données
tous les éléments appartenant à une rubrique à laquelle l’utilisateur n’a pas accès
(soit il n’est pas connecté, soit il ne fait pas partie d’un groupe autorisé). Ce code
est bien évidemment adapté au fonctionnement par groupe (alors que le plugin
06/01/2007 22:05
10 sur 38
"accès restreint fonctionne par zones) mais reste le même dans son principe de
filtrage. Je cite donc textuellement l’explication donnée par l’inventeur de ce
système cf doc du plugin "accès restreint"
[http://www.spip-contrib.net/ecrire/?exec=articles&id_article=1420] :
"L’intérêt de cette démarche, c’est qu’elle fonctionne sur toutes les boucles, donc
tout le site se trouve instantanément sécurisé sans aucune modification de
squelette. Il n’y a pas de risque d’oublier un morceau.
Ce plugin nous garantie l’absence de fuite liée a de nouvelles fonctionnalités de
SPIP (comme les modèles de 1.9.1 qui seraient une belle faille pour ceux qui
sécuriseraient du contenu au moyen des squelettes).
Le principe même de fonctionnement du plugin acces-restreint est de ’supprimer’
du résultat des boucles tout ce que le visiteur n’a pas le droit de voir. Ainsi les
zones à accès réservées sont invisibles pour qui n’y est pas habilité.
N’ayez donc aucune crainte en ce qui concerne les robots, les moteurs de
recherche, ou les fichiers de backend. Le filtre est infaillible.
Ce principe de fonctionnement permet au plugin de filtrer le contenu publié sans
modification du squelette. Cela permet aussi d’avoir des menus (liste de rubriques)
cohérents avec le contenu effectivement accessible. Bref c’est un parti pris, qui fait
son efficacité même."
Donc vous pouvez dormir sur vos deux oreilles : pas de fuites possibles !
Du point de vue du cache, pour minimiser son volume tout en obligeant le recalcul
des pages selon les droits de l’utilisateur, (et en utilisant un principe toujours
pompé sur le plugin accès restreint !), il sera créé un fichier de cache par
combinaison de rubriques interdites : donc si un utilisateur affiche une page,
celle-ci sera tirée du cache correspondant au groupe de rubriques auxquelles il a
accès, ainsi là également, pas de risque d’indiscrétions.
8. Outils à disposition pour les squelettes :
[v1.0.2]Selon
le type de site utilisant ce plugin il peut apparaître le besoin de
[v1.0.2]
vouloir afficher une liste intégrale des rubriques (ou articles, brèves) c’est à dire y
compris les éléments à accès restreint qui sont normalement invisibles. La version
[1.0.2] intègre donc le critère tout_voir qui permet de réaliser cela [2].
De façon complémentaire, si on utilise ce critère il est utile de
pouvoir "marquer" par une icone les titres des éléments à
Résultat du filtre
"accesgroupes_visualise" accès restreints : le filtre |accesgroupes_visualise , utilisable
sur les #BALISEs des boucles ARTICLES, RUBRIQUES ou BREVES,
permet d’ajouter une icone (par défaut cadenas-24.gif ) devant la balise si l’élément
fait partie d’une rubrique à accès restreint.
06/01/2007 22:05
11 sur 38
Exemple typique d’utilisation de ce critère et du filtre : modification du fichier
inc-rubriques.html qui fait le menu latéral des rubrique de la dist :
<B_rubriques>
<div class="rubriques">
<h2 class="menu-titre"><:rubriques:></h2>
<ul>
<BOUCLE_rubriques(RUBRIQUES) {racine} {par num titre,
titre}{tout_voir}>
<li>
<a href="#URL_RUBRIQUE"[
class="(#EXPOSE)"]>[(#TITRE|couper{80}|accesgroupes_visualise{#ID_
<B_sous_rubriques>
<ul>
<BOUCLE_sous_rubriques(RUBRIQUES) {id_parent}
{par num titre, titre}{tout_voir}>
<BOUCLE_test_expose(RUBRIQUES)
{id_enfant}{tout_voir}>#EXPOSE{'
'}</BOUCLE_test_expose_total>
<li><a href="#URL_RUBRIQUE"[
class="(#EXPOSE)"]>[(#TITRE|couper{80}|accesgroupes_visualise{#ID_
<BOUCLE_re(BOUCLE_sous_rubriques){tout_voir}></BOUCLE_re>
</li>
</B_test_expose>
</BOUCLE_sous_rubriques>
</ul>
</B_sous_rubriques>
</li>
</BOUCLE_rubriques>
Remarque : le paramètre #ID_RUBRIQUE du filtre accesgroupes_visualise est
obligatoire !
Si l’image (cadenas) utilisée ne vous plait pas, ce filtre vous offre la possibilité de
choisir un autre fichier image en passant le nom de ce fichier en second paramètre
du filtre. Exemple pour utiliser le fichier cadenas-petit.png placée dans le
répertoire /img de votre dossier de squelette :
[(#TITRE|couper{80}|accesgroupes_visualise{#ID_RUBRIQUE,
#CHEMIN{img/cadenas-petit.png}})]
06/01/2007 22:05
12 sur 38
9. Ce qu’il reste à faire :
Ainsi que je le mentionne par 2 fois plus haut, l’idée pour la suite des
développements est de réaliser un filtrage complet de l’espace privé afin que,
comme pour l’espace public, un utilisateur ne voit que les rubriques auxquelles il
à accès. Cela concernerait donc la liste des rubriques affichées dans la page
d’accueil de /ecrire,
/ecrire les sous-rubriques affichées dans /exec=naviguer , les
rubriques et articles affichés dans /exec=articles_tous , le navigateur rapide de
rubriques du bandeau et surtout le mini-navigateur ajax de choix de la rubrique
lors de la création d’un article ou d’une sous-rubrique (afin d’empécher un auteur
de créer un article dans une rubrique à laquelle il n’a pas accès, ce qui, dans cette
version, l’empèche ensuite d’y accéder dès qu’il l’a enregistré une fois).
comme suggéré dans ce message [#forum388613] du forum, la prochaine version
devrait intégrer des groupes basés sur l’adresse IP du poste connecté (groupe =
plages d’adresses IP)
Cela permettra de gérer des restrictions d’accès différents selon que l’accès au
spip se fait depuis l’intranet ou internet ou selon le sous-réseaux de l’intranet
etc...
Pour cette partie, soyez patients : on y travaille !
comme suggéré par le forum public de la version précédente de cette contrib on
pourrait aussi imaginer :
que les restrictions d’accès puissent s’appliquer au niveau des articles (et pas
seulement au niveau des rubriques)
que les groupes puissent êtres récupérés à partir d’un LDAP
Pour ces 2 points, on y travaille PAS mais toutes les bonnes volontées sont les
bienvenues... et comme pour beaucoup d’autres plugins, afin de faciliter le
developpement collaboratif, vous trouverez l’ensemble des fichiers en cours sur le
SVN de spip-zone !
et, bien sûr, toutes les traductions du fichier de langue sont également les
bienvenues (le fichier accesgroupes_en.php livré avec cette version est super
incomplet...)
P.-S.
Historique des versions :
V0.1 - 16 juillet 2005
version initiale avec gestion multilingue
v0.2 - 02 août 2005
maj pour compatibilité avec MySQL 3.23 la table jpk_auteurs_groupes devient jpk_groupes_auteurs
correction affichage des titres de rubriques typo()
v0.3 - 07 août 2005
Ajout d’un bouton pour la suppression d’un groupe inactif Correction du test d’accès, utilisation du
login au lieu de l’id_auteur
v0.4 - non diffusée
06/01/2007 22:05
13 sur 38
v0.5 - publiée avec un exemple de protection des articles dans l’espace /ecrire/ Attention, les
fichiers ont été renommés !!!
v0.61 - intégration des sous-groupes et des status comme membres possibles des groupes,
installateur automatique des tables dans la base de donnée de spip, préfixage des tables jpk_,
"explorateurs" de groupes dans l’interface de gestion.
v0.7 : version finalisée pour SPIP < 1.9. Correction du bogue de la modification / suppression d’un
groupe, possibilité de séparation privé / public, possibilité de demande d’inscription dans un
groupe par formulaire. Passage en BOUCLE de la restriction de l’espace public + filtre + critère pour
configurer les squelettes.
v 1.0 : passage en plugin pour spip 1.9
Filtrage des éléments à accès restreint directement dans les requètes SQL des boucles par surcharge
des fonctions du core. Gestion du cache en fonction des combinaisons de rubriques restreintes pour
éviter les mauvaises surprises. Possibilité de modifier le propriétaire d’un groupe par les admins
généraux. Amélioration du traitement des messages de demande d’accès. Marquage des groupes
désactivés dans l’interface admin.
v 1.0.1 : filtrage des articles en mode "révision" ( ?exec=articles_versions)
v 1.0.2 : implémentation du critère tout_voir et du filtre accesgroupes_visualise
Notes
[1] NB : c’est la dernière fois que je fais l’effort d’assurer la compatibilité avec les versions de cette
contrib pour les spip 1.8 !
[2] tout_voir est lui aussi un dérivé du plugin acces_restreint : encore une fois, merci Cedric !
6 janvier 2007 10:18, par Philippe Mercier
Bonjour,
Merci pour votre travail qui me semble d’autant plus colossal que je me limite a des copier coller
dans mes squelettes incable d’écrire du code. Je n’ai rencontré aucun soucis pour la mise en
place du plugin, vraiment bravo.
Maintenant je cherche
1) a afficher un message de bienvenue à un visiteur loguer du genre : Bonjour "Alain Dupond" 2)
A diriger le visiteur dés qu’il ce log sur la rubrique où il a des droit
Si quelqu’un peu m’aider je précise mon objectif je prépare un site de mariage et je vais proposer
à mes clients d’avoir une page avec leur vidéo voir www.digitvideo.info on peu tester avec le login
Myriam&Richard et le mot de passe Myriam&Richard
6 janvier 2007 17:01, par cy_altern
Ces 2 points ne relevant pas du fonctionnement de ce plugin, je te conseille de regarder la doc
de http://spip.net/fr [http://spip.net/fr] (spécialement la page sur les formulaires
http://www.spip.net/fr_article1827.html [http://www.spip.net/fr_article1827.html]).
Tu peux éventuellement personnaliser la page de login livrée avec ce plugin
(/acces_groupes/inc_accesgroupes_login.html)
Enfin, pour "diriger le visiteur dés qu’il ce log sur la rubrique où il a des droits" il te faudra
définir cette rubrique puisque ce plugin ne défini nulle part de rubrique affectée à un utilisateur.
06/01/2007 22:05
14 sur 38
4 janvier 2007 18:12, par danou9
Bonjour,
ma config : ie6, SPIP 1.9 configuré pour multisites, Squelette Recit-FP partenaires (utilise des
mots clés), pas de plugins installés
le problème : dans la partie administration les icônes sont inversés de droite à gauche, les liens
sur les rubriques ne fonctionnent plus, ceux qui fonctionnent provoquent des erreurs
merci
Pas super précis comme rapport de bogue... alors quelques indications quand même :
Passe en spip 1.9.1 avant toute chose
Essaie avec un navigateur digne de ce nom (Firefox, Opéra, Safari, Konqueror...) histoire de
savoir si ton problème est spécifique d’IE ou non
Si tu veux que je comprenne ce qui se passe, une capture d’écran serait bienvenue
Problème de création d’un groupe avec IE7 [plugin accès restreint par groupes]
4 janvier 2007 10:13, par Jean-Pierre L
Bonjour,
Nouveau sur ce site, je voudrais vous informer que je rencontre exactement les mêmes
problèmes que Fred H. mais avec la version 7 d’internet explorer ; à savoir l’erreur 1064, les
mêmes soucis d’affichage du formulaire de création et l’erreur mysql avec la non création du
nouveau groupe.
Je profite de mon passage sur ce forum pour vous féliciter sur la qualité et le sérieux de votre
travail et vous remercier pour l’aide très précieuse que vous apportez au novice que je suis.
Mes meilleurs voeux à tous,
Jean-Pierre
Problème de création d’un groupe avec IE7 [plugin accès restreint par groupes]
C’est corrigé pour le bogue d’affichage : cf #forum390146 [#forum390146]
Idem pour le bogue MySQL : pas moyen de le reproduire, que ce soit avec IE6 ou IE7... Mais peut
être aura t’il disparu avec la correction du bogue d’affichage ?
Erreur lors de l’ajout d’un auteur à un article
3 janvier 2007 15:57, par Chris
Merci pour cette très bonen contribution.
Avec le plugin activé, quand un auteur est ajouté à un article, après la validation la page se
recharge complètement en affichant uniquement la partie concernant les auteurs, et tous les
autres éléments de l’interface ne sont pas affichés. Comment corriger ce souci ?
06/01/2007 22:05
15 sur 38
Merci.
Erreur lors de l’ajout d’un auteur à un article
C’est corrigé et disponible dans le zip en téléchargement d’ici 1/2 heure.
Alors soit tu remplace ton fichier /acces_groupes/inc/accesgroupes_prive.php par celui du zip,
soit tu modifie ce fichier à la main :
ligne 145, remplacer
echo formulaire_editer_auteurs($cherche_auteur, $ids, $id_article,$flag_editable) ;
par
echo "\n<div id=’editer_auteurs-$id_article’>" ;
echo formulaire_editer_auteurs($cherche_auteur, $ids, $id_article,$flag_editable) ;
echo "</div>" ;
Pb avec IE6
27 décembre 2006 08:34, par Fred H
Bonjour Je voudrais juste signaler un problème constaté avec la version 6 d’internet explorer. le
formulaire de création d’un nouveau groupe ne s’affiche pas correctement : à la question
"autoriser les inscriptions" il n’y a qu’une seule case à cocher, alors que les mots "oui" et "non"
apparaissent bien. De plus lorsqu’on valide la création d’un groupe, il y a une erreur mysql et le
groupe n’est pas créé.
l’erreur est la suivante : "1064 : You have an error in your SQL syntax ; check the manual that
corresponds to your MySQL server version for the right syntax to use near ’)’ at line 2 "
Ce problème n’a pas été rencontré avec firefox.
Merci pour votre travail
Fred H
Pb avec IE6 et IE7
le formulaire de création d’un nouveau groupe ne s’affiche pas correctement : à la question
"autoriser les inscriptions" il n’y a qu’une seule case à cocher, alors que les mots "oui" et "non"
apparaissent bien
C’est corrigé : un guillemet fermant de trop qui masquait la balise du 2eme INPUT (celui du
"non").
Alors soit tu récupère le fichier /acces_groupes/exec/accesgroupes_admin.php corrigé dans le
zip qui sera disponible sur la zone d’ici 1/2 heure, soit tu fais la correction "à la mano" : fin de la
06/01/2007 22:05
16 sur 38
ligne 558 de ce fichier, remplacer
"\">" ;
par
">" ;
En revanche je n’ai pas pu reproduire l’erreur MySQL que tu signale...
Le plugin accés restreint par groupes - un exemple de test en situation
21 décembre 2006 14:35, par NicolasR
Pour information, un article présentant le test en situation de ce plugin sur un squelette Sarka :
http://p7app.geneve.ch:8007/spip/ar...
[http://p7app.geneve.ch:8007/spip/article.php3?id_article=286 ]
15 décembre 2006 13:10, par Emmanuel LIRON
Bonjour,
Je suis en train de passer le site de notre lycée en spip 1.9.1 et Eva 2.3.
http://lcs.lf1f77.ac-creteil.fr/ webmaster.etab/
Le plugin nous intéresse beaucoup, sur un premier test, il fonctionne bien : en se connectant sur
l’espace privé, puis en retournant visiter le site, les rubriques restreintes et les articles
apparaissent.
Mais si on clique sur Accueil, on retrouve le site initial, sans les rubriques restreintes.
Une solution ?
Merci d’avance
15 décembre 2006 19:12, par cy_altern
Il y a de fortes chances que cela soit lié à un cache. Pour savoir duquel il s’agit : (cache
navigateur ou cache spip),
est ce que les liens admins ("Recalculer cette page" et autres en haut à droite) sont affichés
sur la page d’accueil quand tu retourne dessus après t’être connecté ? Si ils sont absents,
c’est donc le cache navigateur : faire Ctrl + F5 pour recharger la page.
si le lien "Recalculer cette page" est présent, que se passe t’il si tu clique dessus (ou si tu
ajoute &var_mode=calcul dans l’url) ? Si les rubriques apparaissent c’est qu’il y a un
problème dans la gestion du cache de spip par le plugin...
06/01/2007 22:05
17 sur 38
Bonsoir,
Merci de ta réponse.
1) Quand je rafraîchis avec CTrl+F5 (firefox), ça ne change pas, et il n’y a pas le bandeau
recalculer la page
2) Quand je rajoute ?var_mode=calcul après l’url, ça fonctionne : le bandeau apparait, ainsi que
les documents restreints.
Petite indication : je débute en spip ( c’est pourquoi j’ai préféré partir d’un squelette tout fait),
donc le site est très basique.
Je peux faire d’autres tests si tu veux.
Merci
Emmanuel
Bonjour,
Je me réponds à moi-même, je pense avoir trouvé :
avec http://lcs.lf1f77.ac-creteil.fr/~webmaster.etab/ ça ne marche pas. avec
http://lcs.lf1f77.ac-creteil.fr/%7Ewebmaster.etab/ ça marche
Ce n’est pas la première fois que le ~ me pose des problèmes. En écrivant ce message, je me
suis rendu compte que le ~ n’apparaît pas dans le message définitif, il faut que je l’encadre
entre deux balises HTML.
Je vais voir si je peux m’en débarrasser. En attendant, en mettant le %7E à la place du ~ dans
l’adresse du site, ça devrait marcher. Et on va pouvoir utiliser ce plugin qui est exactement ce
qu’il nous faut !
Cela dit, si c’est le plugin qui n’aime pas les ~, ça peut être utile de le corriger. Tous les sites
persos du serveur sont du type username, et ce plugin peut être aussi extrêmement utile sur
un site perso.
Merci d’avance
Emmanuel
Où est passée ma page 404 ?
7 décembre 2006 19:28, par Frédéric TARAUD
Bonjour, et merci pour ce super plugin ! Le critère tout_voir de la version 1.0.2 est vraiment une
bonne idée.
J’ai cependant un petit problème...
J’ai ajouté aux pages "articles", "rubriques" et "brèves" le code de " filtrage avec informations "
dans la boucle qui va bien afin d’être envoyé sur le formulaire de login, et ça fonctionne très bien
dans le cas où l’on tente d’accéder à une ressources restreinte.
Par ailleurs, si je tente d’appeler une page qui n’existe pas, par exemple spip.php ?page=agendas
s
à la place de spip.php ?page=agenda , j’ai la page 404. Tout va bien.
Par contre si maintenant j’appelle un article n°100 qui n’existe pas (spip.php ?article100) j’ai une
06/01/2007 22:05
18 sur 38
page blanche...
Si j’enlève le code de filtrage, je retrouve ma page 404 dans les deux cas...
C’est quoi mon erreur ?
Merci d’avance !
erreur non-reproductible de mon côté... Désolé mais si j’ajoute :
',''})<INCLURE{fond=inc_accesgroupes_login}{skel=#CHEMIN{inc_accesgroupes_login
<//B_article_principal>
en fin du fichier article.html j’obtient (comme prévu !) la page 404 pour une page qui n’existe
pas (http://extranet-eze.dyndns.org/port...
[http://extranet-eze.dyndns.org/portail/spip_191/spip.php?article200&var_mode=recalcul ]) et
la demande de login si j’essaye d’accéder à une rubrique protégée
(http://extranet-eze.dyndns.org/port...
[http://extranet-eze.dyndns.org/portail/spip_191/spip.php?article97&var_mode=recalcul ])...
Alors cette erreur n’étant pas (à priori !) liée à un bogue, elle doit venir de ta config... Tu dois
regarder du côté de ton squelette d’abord puis (éventuellement...) si tu n’as pas un plugin qui
"trafique" le squellette de la page 404 (fichier 404.html).
Je ne doute pas que l’erreur soit de mon côté, mais j’aurai besoin de quelques conseils pour la
trouver...
Voici ce que j’ai fait (en local) :
J’ai retiré mon squelette, et utilisé la "dist"
J’ai ajouté le filtrage [(#ID_ARTICLE|accesgroupes_article_restreint| etc... dans
les pages article et rubrique de la dist
J’ai désactivé de tous les plugins, sauf le tiens...
J’ai vidé les caches se Spip et du navigateur.
Résultat : même problème de page blanche quand j’appel un article ou une rubrique qui
n’existe pas...
En fait si je regarde le code source de cette fameuse page blanche, je constate que je suis arrivé
dans la boucle </BOUCLE_article_principal>...<//B_article_principal>, mais
que rien ne se passe (je n’ai que les commentaires que j’y ai placé, sans aucun code).
Les questions que je me pose sont les suivantes :
quel est le mécanisme d’appel de la page 404 dans le cas d’un article qui n’existe pas : la
page article est-elle appelée, ou l’erreur est-elle détectée avant ?
06/01/2007 22:05
19 sur 38
Autrement dit, le code ajouté en fin de page gère-t-il à la fois le cas d’un article restreint ou
absent, ou seulement restreint ?
Merci d’avance pour tes réponses
[Résolu] Où est passée ma page 404 ? Sans commentaire...
Je me répond à moi même car j’ai trouvé :
J’avais placé un commentaire avant la ligne de filtrage qui était encadrée avec :

Que j’ai remplacé par :
[(#REM) mes commentaires ]
et ça marche !
Etonnant non ? D’autant que j’ai des commentaires utilisant la première syntaxe partout dans
cette page....
Suggestion pour un critère "voir_groupe"
5 décembre 2006 22:18, par Dominique T
Le nouveau critère "tout_voir" permet de parcourir tous les articles même ceux restreints à l’un ou
l’autre groupes. Mais, il n’est pas possible de spécifier l’identifiant d’un groupe particulier.
Un critère "voir_groupe groupe_Id" filtrant les articles non protégés ou accessibles par un groupe
particulier serait particulièrement utile pour définir un patron "SPIP-liste" reprenant les nouveaux
articles d’un groupe particulier.
Que pensez-vous de l’utilité d’une telle suggestion ? Est-ce difficile à réaliser ?
Encore félicitation pour l’utilité et maintenant la simplicité d’installation de ce plug-in.
Suggestion pour un critère "voir_groupe"
Bonne idée de fonctionnalité supplémentaire : hop ! direct dans la TODO list !
A priori ce n’est pas *très* compliqué à faire mais en ce moment je n’ai pas le temps de m’en
occuper (d’abord sortir le plugin csv2spip !).
Alors si un codeur veut s’en occuper qu’il me contacte via ce forum, on s’arrangera pour mettre
en route une version 1.0.3 sur le SVN de la zone.
5 décembre 2006 16:38, par Seb
Bonjour,
après activation du plugin, je n’ai pas les choix de restrictions qui apparaissent au niveau des
fiches d’auteur... c’est dommage car tout marchait bien auparavant sur mon 1.9 et après passage
au 1.9.1 c’est la misère...
j’ai essayé également le plugin accès_groupe mais il ne me satisfait pas, et je suis repassé à
accès_restreint et depuis, plus rien !!
06/01/2007 22:05
20 sur 38
help ????
5 décembre 2006 16:40, par Seb
oups... je suis pas dans le bon forum là... je pensais au plugin accès_restreint... pardon....
5 décembre 2006 15:11, par Korben
Bonjour,
Est il possible de brancher ce plugin sur une base d’utilisateur Invision Power Board ?
Cordialement,
Branchement du plugin acces_groupes sur une base Invision Power Board ?
Techniquement ce genre de connexion est toujours possible mais ça nécessitera de remplacer
toutes les requêtes MySQL qui font appel à la table spip_auteurs par des requêtes équivalentes
dans la base utilisateur de IPB... avec tous les problèmes de correspondance de champs entre
ces 2 tables (pour mémoire, acces_groupes utilise les champs nom,
nom id_auteur , statut de la table
spip_auteurs ). De plus ça nécessitera aussi des correspondances plus "acrobatiques" pour les
tables spip_auteurs_rubriques et spip_auteurs_messages .
D’un point de vue licence, vu que IPB n’est pas un logiciel libre alors que acces_groupes est
distribué sous licence GPL (donc "contagieuse"), le plugin ainsi modifié devra être GPL...
Bref, n’étant ni un utilisateur de IPB (et à 69,95$ la licence annuelle je risque pas de le devenir !)
ni un fan des solutions propriétaires, non seulement je ne ferais aucun effort pour ce portage
mais en plus, si tu souhaitais t’en occuper, ne compte pas sur moi pour une quelconque
adaptation du code...
Dans le genre de branchement de ce plugin sur une base utilisateur différente de celle de SPIP,
je serais beaucoup plus motivé pour une "connexion" sur les groupes/utilisateurs d’un annuaire
LDAP .
Branchement du plugin acces_groupes sur une base Invision Power Board ?
8 décembre 2006 13:33, par Coyote
Il serait par contre possible d’utiliser le plugin d’ authentification des auteurs via une BD externe
[http://zone.spip.org/trac/spip-zone/changeset/2342]...
Le plugin accés restreint par groupes Help !
2 décembre 2006 10:50, par bLAISEAU
Bonjour
Ce plug in marche du tonerre, cependant comment faire pour éviter que le auteurs ou
appartenant a un groupe ne voit tte la liste déroulantes des autres rubriques ? Car lorsque je
choisi d’écrire un nouvel article j’ai tjrs la posibilité de rentrer ds n’importe quelle rubrique, bien
sûr le plug in a fait que je ne peux pas poster mais cela est troublant pour les utilisateurs il
parait... auriez vous une idée pour m’aider à résoudre ce soucis ?
06/01/2007 22:05
21 sur 38
cette question à déja été traitée dans ce forum : http://www.spip-contrib.net/Le-plug...
[http://www.spip-contrib.net/Le-plugin-acces-restreint-par#forum388857 ]
Pour aller plus loin : tu peux essayer la version 1.1 qui assure le masquage des rubriques
restreintes dans la liste de choix des rubriques lors de la création d’un nouvel article. Cette
version (svn ://zone.spip.org/spip-zone/_plugins_/_dev_/acces_groupes) est un essai "cul de
sac" vu les contraintes de mises à jour qu’elle imposerait lors des évolutions des versions de
spip. Elle n’est accessible que par SVN, et son développement est stoppé en attendant la
squelettisation de l’espace privé... donc AUCUNE garantie quand à son fonctionnement !
Le plugin accés restreint par groupes sos détresse !
helas je n’ai pas svn et effectivement la version 1.1 est trop contraignante, que puis je faire ?
attendre la squelettisation du côté privée ? je m’y atelerais bien mais j’ai pas les épaules en
spip pour hélas ?
2 décembre 2006 15:36, par imagine
Problème similaire avec le squelette ’’MiniGriSpip’’.
Les articles sont invivibles mais le menu affiche toutes les entrées, même celles inaccessible :(
En fait, ce n’est pas le même problème, c’est sur mon site public que le menu ne se met pas à
jour, j’ai du rater une étape :(
J’ai règlé le problème en changeant de squelette :)
Importer des comptes à partir d’un fichier
J’aimerais importer mes rédacteurs et mes administrateurs depuis un fichier csv.
En retouchant le plugin "Importer des auteurs
[http://www.spip-contrib.net/Plugin-Importer-des-auteurs ]", j’ai réussi à importer les
rédacteurs et auteurs avec leurs mots de passe.
Maintenant, j’aimerais importer les groupes (profs, eleves...) et les sous-groupes (classes,
matières...) mais je ne sais pas quels champs renseigner dans "spip_accesgroupes_auteurs,
spip_accesgroupes_acces et spip_accesgroupes_groupes".
Je ne sais même pas si ce sont les seuls fichiers à renseigner :(.
Une petite aide m’aiderais, csv2spip
[http://www.spip-contrib.net/csv2spip-gestion-des-utilisateurs ] n’est pas encore près
06/01/2007 22:05
22 sur 38
Créer des groupes d’accès à partir d’un fichier CSV : sortie imminente du plugin csv2spip
tu tombe à pic : je suis en train de finaliser la version plugin de csv2spip qui permet de
créer automatiquement les groupes de acces_groupes à partir des sous-groupes déclarés
dans le fichier CSV que tu importe.
D’ici 1 ou 2 jours ça sera testable : tu sera alors vraiment le bienvenu pour faire le
bèta-testeur ! Je poste sur ce forum dès que le zip du plugin csv2spip sera disponible.
J’attends avec impatience :)
hé génial ! toi aussi tu tombes a pic je suis très interressée :)
Il me faut absolument mes groupes pour la semaine prochaine, je vais chercher comment
les créer automatiquement (600 utilisateurs à placer dans 1 groupe et 1 sous-groupe :( pas
envie de le faire à la main).
Testerez csv2spip quand il sera là
Créer des groupes d’accès à partir d’un fichier CSV : sortie imminente du plugin
csv2spip
ça fait déja au moins 10 jours que la version "pre-released" de csv2spip en plugin est sur
la zone : svn ://zone.spip.org/spip-zone/_plugins_/_dev_/csv2spip . Cette version est
opérationnelle, il ne doit rester que quelques petits problèmes lors de la mise à jour des
rubriques d’admins restreints (mais à priori puisque tu es à la phase première création des
comptes, tu n’es pas concerné).
Puisqu’apparemment tu n’as pas été trifouiller dans la zone pour trouver cette version,
j’en conclu que tu n’utilise pas SVN et que tu attend donc un zip... c’est donc par là :
http://extranet-eze.dyndns.org/port...
[http://extranet-eze.dyndns.org/portail/spip_191/IMG/zip/csv2spip.zip ]
tu as règlé le problème des rubriques ?? tu as fait comment ds ton squelette ? ç’a
m’interresse grandement je frôle la déprime avec mon problème
30 novembre 2006 17:41, par Korben
Merci pour ce plugin, il est génial ! Par contre, j’avais aussi le plugin fckeditor 0.2 (trouvable sur
le SVN) et celui-ci est toujours actif mais le bouton que j’avais sur la page d’edition d’un article
06/01/2007 22:05
23 sur 38
pour lancer le fckeditor a disparu...
Strange non ? Il n’y a pas moyen d’arranger ca ?
Voir en ligne : Korben [http://www.korben.info]
30 novembre 2006 23:34, par cy_altern
Strange ? non : le plugin fckeditor doit surcharger la fonction exec_articles_edit() pour faire
apparaitre le bouton en question dans exec=article_edit et comme acces_groupes surcharge lui
aussi cette fonction (pour permettre le filtrage des articles appartenant à des rubriques
restreintes) et qu’il est situé avant fckeditor dans l’ordre alphabétique des noms de plugins,
cette surcharge bloque celle faite par fckeditor donc le bouton n’apparaît plus...
"Il n’y a pas moyen d’arranger ca ?" : il suffirait d’intégrer la surcharge de fckeditor dans celle de
acces_groupes... mais n’étant pas un fan des éditeurs WYSIWYG, ne compte pas sur moi pour
m’en occuper ! En revanche si tu veux proposer un patch, ne te gène pas : je l’intégrerai dès que
tu me l’auras envoyé. Pour info : la fonction exec_articles_edit() à modifier est codée dans le
fichier /plugins/acces_groupes/inc/accesgroupes_prive.php .
8 décembre 2006 11:45, par Korben
Hello,
merci pour tes indications. J’ai regardé comment c’etait fait dans le source mais n’etant pas un
PHP hardcore coder, je n’ai aucune idée de comment surcharger le truc...
Quelqu’un pourrait il m’aider ?
Merci
30 novembre 2006 01:44, par frankybee
Je me lance de spip 1.8.3 à 1.9.1 avec ce plugin en boni ! (Je suis toujours avec les squelettes de
base)
Il y a un truc que je ne pige pas. Je dois donner des accès à des sous-sous-rubriques (ex : 1.1.5
et 1.1.7) à un utilisateur A, sans autoriser l’accès à la totalité de la rubrique-mère (1.1). J’ai donc
donné les autorisations équivalentes dans le gestionnaire d’accès à cet utilisateur A et restreint
l’accès à 1.1 en donnant l’accès à cette rubrique qu’à l’admin principal.
Mon problème : Dans une boucle de type plan, comme (1.1) n’est pas accessible à utilisateur A,
les (1.1.x) autorisées n’apparaissent pas pour cet utilisateur. Le fil d’ariane saute également cette
rubrique lorsque utilisateur A se trouve dans 1.1.7 (Accueil > 1 > 1.1.7)
Comment arriver à afficher la hiérarchie ascendante dans un menu ou un fil d’ariane dans un cas
comme celui-ci ? - Merci de vos lumières !
Afficher la liste de toutes les rubriques même les restreintes
Le problème que tu rencontre est lié au fait que par défaut ce plugin masque toutes les
rubriques (et leurs contenus) qui ne sont pas accessibles à l’utilisateur en cours : donc si la rub
06/01/2007 22:05
24 sur 38
1.1 est restreinte à l’admin général seul, personne d’autre que lui ne pourra voir les
sous-rubriques 1.1.5 et 1.1.7 dans les menus de rubriques du squelette dist.
Jusqu’à il y a 2 jours je t’aurais répondu : "déplace tes rubriques 1.1.x dans une rubrique parent
non-restreinte" et basta !
Mais tu as de la chance : suite à quelques échanges sur l’irc #spip [irc://irc.freenode.net/spip
[ irc://irc.freenode.net/spip ]
d’autres utilisateurs du plugins m’ont convaincu qu’il devait être possible de pouvoir afficher la
liste de toutes les rubriques/sous-rubriques même les restreintes .
Alors si tu attend encore quelques jours (le temps de finaliser), tu pourra mettre à jour ce plugin
avec la version 1.0.2 qui implémente le critère tout_voir (comme d’hab’ pompé sur le plugin
accès_restreint : merci Cedric !) et le filtre accesgroupes_visualise qui permet d’ajouter une
image (par défaut ecrire/img_pack/cadenas-24.gif) devant les #BALISES des
rubriques/articles/breves appartenant à une rubrique restreinte. Bref : ça devrait te permettre de
faire apparaître les sous-rubriques 1.1.x dans les menus rubriques. Pour le HOWTO des
modification de squelettes nécessaires : repasse par ici, cet article expliquera comment faire.
acces_groupes : sortie de la version 1.0.2 qui permet le listage des éléments restreints
C’est fait : la version stable est désormais la 1.0.2 qui supporte le critère tout_voir et le filtre
accesgroupes_visualise pour pouvoir afficher des listes de rubriques (mais aussi articles,
brèves...) y compris ceux appartenant à des rubriques restreintes. Voir le point 8. de cet article
pour leur intégration dans les squelettes.
bonjour,
Mais où trouver cette version ?
la 1.0.2 étant désormais la version "officielle", il te suffit de (re)télécharger le zip du plugin. Vu
que le serveur de la zone a eu un problème hier, utilise le mirroir
http://miroirspip.ventre.name/build... [http://miroirspip.ventre.name/builds/spip-zone/ ], la
version qu’il propose est à jour.
merci bien :)
merci t’es un géni ça marche impec !!! bon j’ai tjrs mon souci pour masquer les rubriques où
les auteurs restreints ne devraient pas avoir accès .... crois tu qu eje devrais modifier le
squelette en supprimant dans le formulaire ecrire un nouvel article la liste déroulante ?
29 novembre 2006 15:28, par cedesguin
Cet excellent plugin semble fonctionner parfaitement chez moi, mais avec ce curieux
avertissement dont je ne sais que faire :
06/01/2007 22:05
25 sur 38
Warning : file(../plugins/plugins_stable/plugin.xml) [function.file] : failed to open stream : No
such file or directory in
/home/cedesguin/domains/desguin.net/public_html/spip/plugins/plugins_s
table/acces_groupes/exec/accesgroupes_admin.php on line 482
Warning : Invalid argument supplied for foreach() in
/home/cedesguin/domains/desguin.net/public_html/spip/plugins/plugins_s
table/acces_groupes/exec/accesgroupes_admin.php on line 484
Je précise que, bien entendu, le fichier "accesgroupes_admin.php" est bien présent là où il est
attendu.
facile : tu as un plantage sur l’ouverture du fichier plugin.xml que la fonction
exec_accesgroupes_admin() utilise pour déterminer quelle est la version en cours (1.0, 1.0.1 ...)
et l’aficher dans le cadre de gauche (dernière ligne : "Version : 1.xx")... L’explication du bogue
est elle également simple : vu que le plugin est dans /plugins/plugins_stables/acces_groupes
ça met en erreur l’ouverture du fichier plugin.xml qui est censé être dans
/plugins/acces_groupes (ou plus précisément dans un répertoire directement dans /plugins ).
Disons que c’est pas une erreur "grave" mais que tu met le doigt sur les limites de la bidouille
utilisée pour récupérer la version indiquée dans le fichier plugin.xml...
Alors 3 solutions :
soit tu place le dossier du plugin directement dans /plugins
soit tu modifie la 4eme ligne de la fonction exec_accesgroupes_admin() du fichier
/exec/accesgroupes_admin.php pour mettre "en dur" la constante
_DIR_PLUGIN_ACCESGROUPES qui indique le chemin du plugin, ce qui devrait donner :
define(’_DIR_PLUGIN_ACCESGROUPES’, ’../plugins/plugins_stables/acces_groupes’) ;
soit tu modifie le code qui permet de définir _DIR_PLUGIN_ACCESGROUPES de façon correcte
quelque soit la position du répertoire du plugin dans l’arborescence de /plugins (cf les 3
premières lignes de la fonction exec_accesgroupes_admin() ) et tu me l’envoie pour que je
fasse la modif du plugin.
bref, t’as le choix... mais autant te dire que ma préférence va à la 3eme solution ;-)
Mille mercis. Étant à la fois surbooké et fainéant, j’opte pour la solution 1. Désolé ;-)
8 décembre 2006 19:44, par ivandps
bonjour j’ai le même problème...que cy_altern
Empêcher de poster dans un groupe auquel l’auteur n’a pas accès :-)
06/01/2007 22:05
26 sur 38
20 novembre 2006 16:40, par Suske
C’est peut-être plus compliqué...
Comme je viens de faire la bêtise, je détaille auu cas où : j’ai omis (comme souvent) de
sélectionner une rubrique avant de poster un nouvel article. Résultat, mon texte est parti dans la
rubrique par défaut, celle qui est la première dans la liste et à laquelle je n’ai pas accès...
POour éviter ça, j’ai donc créé une rubrique bidon intitulée "****** Sélectionnez une rubrique à
laquelle vous avez accès ! ******", qui, grâce aux étoiles, devrait rester la première dans la liste.
J’y ai donné accès à tous les rédacteurs. C’est une solution honorable mais pas très structurelle...
vu le fonctionnement actuel du filtrage de l’espace privé, c’est effectivement une erreur
possible : un rédacteur peut choisir une rubrique à laquelle il n’a pas accès comme rubrique
parent d’un nouvel article... une fois qu’il a fait le premier enregistrement, il ne peut plus
l’afficher !
Ta solution est une bonne ruse pour limiter la casse au niveau des oublis... mais c’est un
problème qui ne devrait plus exister dans la prochaine version puisqu’avec la squelettisation de
l’espace privé (spip 1.9.2 ?) il sera possible d’appliquer la méthode de filtrage des requêtes
MySQL donc de masquer les rubriques restreintes dans toutes les pages de l’espace privé.
Donc, une fois de plus, patience...
J’avais pas lu l’article "à fond" et viens de découvrir que ceci y était expliqué... Désolé pour le
bruit.
Filtrer l’accès via l’historique des modifications d’articles
Salut,
Bravo, merci, super...
Dans une config "public :ouvert/privé :fermé", j’ai découvert par hasard que l’accès via
l’historique des modifications n’est pas filtré. Pas rhédibitoire mais à implémenter peut-être
quand même ;-)
Mes deux sous.
Suske
Voir en ligne : Installation du plgin "Accès restreint par groupe"
[http://blogs.brubel.net/spip.php?article31 ]
ouais... y’a un trou là : il va falloir s’en occuper !
Merci pour l’info : je poste sur ce billet lorsque le patch sera sorti.
06/01/2007 22:05
27 sur 38
(PS : bonne exemple d’utilisation de ce plugin ton site de blogs...)
c’est corrigé !
sortie de la v 1.0.1 : support de exec=articles_versions pour le filtrage de l’espace privé
cette version constitue la version _stable_ de ce plugin et sera celle proposée au téléchargement
sur la zone http://zone.spip.org/files/spip-zon...
[http://zone.spip.org/files/spip-zone/acces_groupes.zip] d’ici 1/2 heure...
Wouaouw ! 10h et 8 minutes après mon message... C’est pas aussi rapide qu’ESJ sur spip-dev
mais chapeau bas quand même :-))
Z’êtes tous comme ça les spipiens ?
24 novembre 2006 14:01, par ver_listes
le plugin n’est pas accessible à cette adresse :
http://zone.spip.org/files/spip-zone/acces_groupes.zip
où se trouve-t-il ?
15 novembre 2006 17:35, par sam
Bonjour, le plugins fonctionne très bien. merci aux créateurs.
mon seul souci se situe au niveau de la configuration pour avoir un filtrage avec information ou la
page d’authentification n’apparait pas ! malgré l’ajout du code dans article.html de mon squelette
MiniGriSpip142 :
code à rajouter :
',''})<INCLURE{fond=inc_accesgroupes_login}{skel=#CHEMIN{inc_accesgroupes_login}
Spip 1 9 1 installé (webmestre de niveau novice ;-) qui attend que la doc sur la nouvelle
architecture spip 1.9 soit publier)
merci de votre aide
06/01/2007 22:05
28 sur 38
16 novembre 2006 12:21, par sam
RE
mon souci c’est que je ne comprends pas le code suivant : <//B_article_principal>
je comprends ce code comme une fermeture de balise. faut-il ajouter une balise au debut du
code de la page article.html du style :
<B_article_principal>
merci de votre aide
ça c’est la syntaxe de base des boucles SPIP : voir le paragraphe " Syntaxe complète " de cet
article de la doc http://www.spip.net/fr_article898.html
[http://www.spip.net/fr_article898.html]
14 novembre 2006 08:43, par Yann974
Bonjour,
Et tout d’abord MERCI pour ce plugin qui apporte des fonctionnalités très importantes pour moi
(et bien d’autres j’imagine !). C’est tout ce que je souhaitais. Vraiment. Seulement voilà, autant en
local (localhost) tout fonctionne à merveille (j’utilise une 1.9.1 [7502]), autant sur le serveur de
mon provideur (même version de SPIP), il y a des soucis. Le plugin semble bien installé mais il
m’est impossible d’obtenir un fonctionnement normal. Je ne peux même pas ajouter de nouveaux
membres dan sle groupe (menu déroulant vide) et tous les autres éléments de l’interface ne
s’affiche pas. (c.f. copie d’écran
http://www.reunion-equitable.asso.re/spip/acces-groupe-dysfonctionnement.png
[http://www.reunion-equitable.asso.re/spip/acces-groupe-dysfonctionnement.png ])
Une idée ?
8 novembre 2006 09:39, par webzone
Bonjour,
En test en local (WAMP, SPIP 1.9.1), il fonctionne. Il ne faut pas oublier de vider le cache de SPIP et
du navigateur (cookie).
J’ai une question toutefois.
Au lieu d’entrer un par un les personnes ayant accès à une partie restreinte (comme exemple
lycée), y a t’il une possibilité de faire par plage d’adresses IP (ex. : seuls les 192.168.100.1 à
192.168.100.254) d’autorisation ou d’interdiction ?
Cas d’une société ayant diverses succursales avec un "intranet maison" et des "intranets par
divisions".
Merci d’avance, et beau travail
06/01/2007 22:05
29 sur 38
restrictions par adresses IP : nouvelle feature du plugin accés restreint par groupes ?
Hé hé ! ça c’est une bonne idée de nouvelle "feature" !
Direct je met sur la TO DO !
Et pour ceux qui aurait envie de participer voila ce qui serait possible si on veut faire un truc
"ergonomique" :
dans l’interface de gestion ajouter un nouveau type de sous-groupe basé sur une plage
d’adresse IP (un champ IP début / un champ IP fin) au même niveau que la sélection des
utilisateurs individuels ou par sous-groupe ou par statut
dans les fonctions de vérification, ajouter une fonction qui permet de tester d’après
$_SERVER[’REMOTE_ADDR’] si l’utilisateur connecté appartient (ou non) a un "groupes
d’adresses IP"
De cette manière il n’y a rien d’autre à modifier, on peut gérer des restrictions d’accès avec les
groupes des plages d’adresses IP exactement comme avec les autres groupes !
Erreur pour Limiter l’accès à la rubrique ?
13 novembre 2006 16:43, par awaqui
Bonjour,
Quand j’essaie d’appliquer la restriction d’accès à un groupe le tableau "Rubriques restreintes
accessibles par ce groupe" reste vide. C’est la seule fonction qui ne marche pas sinon je peux
inclure des auteurs, des sous groupes et des statuts.
J’utilise SPIP 1.9.1 sur mysql 5.0.24a
Voici le journal spip.log
Nov 13 16:28:38 10.133.2.99 (pid 984) Nov 13 16:28:38 10.133.2.99 (pid 984) POST
/spip/ecrire/ ?exec=accesgroupes_admin
Nov 13 16:28:39 10.133.2.99 (pid 984) Nov 13 16:28:39 10.133.2.99 (pid 984) - CREATE
TABLE IF NOT EXISTS `spip`.spip_accesgroupes ()
Nov 13 16:28:39 10.133.2.99 (pid 984) Nov 13 16:28:39 10.133.2.99 (pid 984) 1064 You have
an error in your SQL syntax ; check the manual that corresponds to your MySQL server version
for the right syntax to use near ’)’ at line 1
Nov 13 16:28:40 10.133.2.99 (pid 984) Nov 13 16:28:40 10.133.2.99 (pid 984) POST
/spip/ecrire/ ?exec=accesgroupes_admin
Nov 13 16:28:40 10.133.2.99 (pid 984) Nov 13 16:28:40 10.133.2.99 (pid 984) - INSERT INTO
`spip`.spip_accesgroupes_acces(id_grpacces, id_rubrique, id_article, dtdb, dtfn, proprio,
prive_public) VALUES("1", "1", "",now(),now(), 0, "0")
Nov 13 16:28:40 10.133.2.99 (pid 984) Nov 13 16:28:40 10.133.2.99 (pid 984) 1264 Out of
range value adjusted for column ’id_article’ at row 1
3 novembre 2006 16:13, par seb
Bonjour, Je comprend pas bien le fonctionnement de ce plugins car en effet il fonctionne bien
pour l’espace public cependant des que je me connecte dans l’espace privé, il n’en tient plus
compte il ne m’empeche pas de consulter les rubriques restreintes meme en ayant mis les
bonnes restrictions je ne comprend pas ????
06/01/2007 22:05
30 sur 38
3 novembre 2006 08:56, par lagamelle
Bonjour, www.comitedromecycliste.fr [http://www.comitedromecycliste.fr]
Mon site fonctionne sous SPIP 1.9.2 alpha 2 SVN [7725] avec le squelette Blip. Jusqu’à présent je
n’avais pas de problème.
En installant votre plugins depuis hier, tout fonctionne dans la partie public pour les accès qui ont
été réservés pour une rubrique "Publications".
Par contre dans la partie privé, quand je suis dans la rubrique "A SUIVRE", si je veux modifier
un article ou une rubrique j’obtiens une page blanche, idem pour la création d’une nouvelle
rubrique ou d’un nouvel article.
J’attends vos infos sur la conduite à tenir concernant ce problème.
Merci pour ce plugins très intéressant. CJ
Mon site fonctionne sous SPIP 1.9.2 alpha 2 SVN [7725]
Cherche pas plus loin, ce plugin est destiné à une version 1.9.1 de spip, et il n’est pas encore
opérationnel sous 1.9.2.
En principe on attend que la "squelettisation" de l’espace privé soit opérationnelle pour adapter
le plugin en utilisant le même principe que pour l’espace public cad le filtrage directement au
niveau des requêtes dans la base.
Donc : patience...
31 octobre 2006 23:50, par BBn
Bravo pour la gestion des accès par groupes !!!
J’ai par contre une petite question : Comment dois-je procéder pour ajouter le login utilisateur au
contexte ? Ceci dans le but d’éviter d’avoir une version "cachée" de ma page sommaire (qui
n’affiche normalement qu’un message de bienvenue et un lien pour se connecter). Une fois
loggué, celle-ci doit afficher un lien déconnecter et les rubriques en accès restreint.
Mon problème, c’est que certaines fois quand je me connecte à mon site, je tombe sur une
version cachée d’une session précédente.
Mon FAI est free et j’ai fraîchement installé la version SPIP 1.9.1 ainsi que la dernière version du
plugin acces_groupe.
En principe tu ne devrais pas avoir besoin "d’ajouter le login utilisateur au contexte" : le
fonctionnement normal de ce plugin est prévu pour gérer le cache en fonction des droits de
l’utilisateur connecté ce qui ne devrait pas te permettre de "tomber sur une version cachée"...
06/01/2007 22:05
31 sur 38
Alors plusieurs pistes possibles :
la version "cachée" ne viendrait elle pas du cache de ton navigateur ?
regarde du côté du squelette de sommaire.html et en particulier au niveau des conditions de
l’intégration du formulaire de login.
enfin, j’ai quand même l’impression que ton problème n’est pas lié au plugin en lui-même
mais à ce que tu pense qu’il "devrait
devrait faire "... En effet ce plugin à pour rôle de masquer les
rubriques restreintes pour les utilisateurs non-autorisés, mais il n’est pas prévu pour faire
"l’aiguillage" entre des pages "connecté/non-connecté"... pour cela vois plutôt cet article de la
doc : http://www.spip.net/fr_article1827.html [http://www.spip.net/fr_article1827.html]
Merci !
31 octobre 2006 11:01, par nico
Merci beaucoup pour ce plugin terrible !
Je trouve super propre, et vraiment très pro !!!! Bravo !
rubriques "vides" en accès privé
25 octobre 2006 16:37, par SPQR
J’ai installé le plugin sur une 1.9.1 : accès public pas de problème, la restriction d’accès
fonctionne correctement, mais par contre en accès privé plus aucune rubrique n’est visible, page
blanche systématique... Si je désactive le plugin, retour à la normale.
C’est à n’y rien comprendre, je n’ai qu’une seule rubrique en accès restreint public et toutes les
autres sont sans restriction ni en privé ni en public.
:-(
rubriques "vides" en accès privé
1er novembre 2006 18:12, par cy_altern
Ca fait pas beaucoup d’infos pour essayer de comprendre/reproduire le problème... Alors il
faudrait préciser :
Quel est le fichier qui te donne page blanche (exec=rubrique_edit ? exec=naviguer ?
exec=articles_tous ?) ??
Que se passe t’il si tu as le plugin actif mais pas de rubrique restreinte ?
ecrire/data/spip.log il te donne quoi quand tu as la page blanche ?
Quels sont les autres plugins actifs ?
... bref donne un peu des billes pour qu’on puisse trouver où le jouet il est cassé...
rubriques "vides" en accès privé -> As-tu vidé le cache ??
AMHA, ce pourrait être un problème de ce genre...
24 octobre 2006 16:07, par livrozetja
Bonjour
Merci d’avoir mis à dispo votre travail Débutant , j’essaie de mettre en oeuvre votre contrib qui
06/01/2007 22:05
32 sur 38
nous serait bien utile
Nous sommes hébéergés chez "ifrance" Nous avons installé SPIP 1.9
et votre plugin "acces groupe"
Voici le message qui apparaît : 1064 : You have an error in your SQL syntax ; check the manual
that corresponds to your MySQL server version for the right syntax to use near ’)’ at line 2
Afficher l’interface textuelle simplifiée
Faut-il adapter des fichiers ?
Merci pour votre réponse
Voici le message qui apparaît : 1064 : You have an error in your SQL syntax ; check the manual
that corresponds to your MySQL server version for the right syntax to use near ’)’ at line 2
Afficher l’interface textuelle simplifiée
A priori ce plugin n’utilise nulle part de requête SQL en rapport avec "Afficher l’interface
textuelle simplifiée" alors cette erreur ne devrait pas être lié à sa présence... Peut être faudrait il
passer ton SPIP en version 1.9.1 ?
1er décembre 2006 14:29, par opopop
Bonjour,
J’utilisais la version 0.7 de la contrib "Accès restreint par groupe" sur mon site Spip1.8.2, et ça
marchait très bien.
J’ai fait une mise à jour de Spip 1.8.2 vers Spip 1.9.1, en déplaçant au préalable mon ancien site
dans un sous répertoire puis j’ai intégré le plugin "Accès restreint par groupe"et j’ai fait la mise
à jour des tables de la base de données en utilisant le script
../plugins/acces_groupes/maj_tables.php
Quand je veux créer un groupe, j’obtiens dans la partie haute de mon espace privé le message :
1064 : You have an error in your SQL syntax. Check the manual that corresponds to your
MySQL server version for the right syntax to use near ’)’ at line 2
Je ne sais pas comment ni où réparer la chose ! Quelqu’un aurait une idée ? ...merci
1er décembre 2006 19:27, par cy_altern
et le fichier /ecrire/data/mysql.log il te donne quoi comme message d’erreur ?
6 décembre 2006 11:12, par opopop
Bonjour,
06/01/2007 22:05
33 sur 38
merci de venir à mon aide si vite !
Voilà, j’ai tout viré mon site spip 1.8.2 et vidé ma base par PhpMyAdmin, réinstallé spip 1.9.1
et copié/collé mes articles depuis mon site en local vers mon hébergeur (OVH) mais lorsque
je tente de créer un groupe d’ accès restreint, Paf ! je retrouve le même message : ’You have
an error in your SQL syntax...’
J’ai regardé le fichier ’mysql.log’ et j’ai ça (mais ça ne me parle pas vraiment) :
Dec 04 14:27:26 81.53.230.251 (pid 23623) POST
/ecrire/?exec=upgrade&reinstall=non
Dec 04 14:27:26 81.53.230.251 (pid 23623) - ALTER TABLE
`decouver`.spip_documents DROP inclus
Dec 04 14:27:26 81.53.230.251 (pid 23623) 1091 Can't DROP 'inclus'.
Check that column/key exists
Dec 04 17:31:11 81.53.230.251 (pid 10341) GET /spip.php?action=cron
Dec 04 17:31:11 81.53.230.251 (pid 10341) - SELECT count(*) AS
nb_acces
FROM
`decouver`.spip_accesgroupes_acces
LEFT JOIN
`decouver`.spip_accesgroupes_groupes
ON
`decouver`.spip_accesgroupes_acces.id_grpacces =
`decouver`.spip_accesgroupes_groupes.id_grpacces
WHERE id_rubrique
= 1
AND actif = 1
AND prive_public != 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
'decouver.spip_accesgroupes_acces' doesn't exist
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 1
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 2
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
06/01/2007 22:05
34 sur 38
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 2
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 3
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 3
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 4
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
06/01/2007 22:05
35 sur 38
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 4
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 5
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 5
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 6
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
06/01/2007 22:05
36 sur 38
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 6
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 7
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
nb_acces
FROM
LEFT JOIN
ON
WHERE id_rubrique
= 7
AND actif = 1
Dec 04 17:31:11 81.53.230.251 (pid 10341) 1146 Table
Dec 04 17:34:15 81.53.230.251 (pid 12333) GET /spip.php?article1
Dec 04 17:34:15 81.53.230.251 (pid 12333) - SELECT id_document FROM
`decouver`.spip_documents_syndic WHERE 0=1
Dec 04 17:34:15 81.53.230.251 (pid 12333) 1146 Table
'decouver.spip_documents_syndic' doesn't exist
Dec 04 18:01:36 81.53.230.251 (pid 30432) GET
/spip.php?article1&var_mode=calcul
Dec 04 18:01:36 81.53.230.251 (pid 30432) 1146 Table
Dec 04 18:11:48 81.53.230.251 (pid 5283) GET /spip.php?article4
Dec 04 18:11:48 81.53.230.251 (pid 5283) 1146 Table
06/01/2007 22:05
37 sur 38
Dec 05 16:20:53 86.199.63.13 (pid 17829) POST
/ecrire/?exec=accesgroupes_admin
Dec 05 16:20:53 86.199.63.13 (pid 17829) - INSERT INTO
`decouver`.spip_accesgroupes_groupes(nom, description, actif,
proprio, demande_acces)
VALUES("Asso345","", 1, 0, )
Dec 05 16:20:53 86.199.63.13 (pid 17829) 1064 You have an error in
your SQL syntax. Check the manual that corresponds to your MySQL
server version for the right syntax to use near ')' at line 2
Dec 05 16:22:39 86.199.63.13 (pid 19276) POST
VALUES("Valorisation
campanaire","", 1, 0, )
Dec 05 17:58:53 86.199.60.22 (pid 17747) POST
VALUES("Le site
web","", 1, 0, )
24 octobre 2006 11:57, par elafargue
Superbe plugin, on commence vraiment à avoir quelque chose de très abouti dans le domaine du
contrôle d’accès.
Une seule remarque : sur mon site, j’ai introduit la notion d’articles à accès restreint, à l’intérieur
de rubriques à accès public en général. Plus précisément, je gère en restreignant l’accès de
certains articles à uniquement leurs auteurs. L’architecture de ce plugin permettrait-elle
d’étendre la notion d’accès restreint non seulement à des rubriques, mais également à des
articles individuels à l’intérieur de rubriques à accès public ?
L’architecture de ce plugin permettrait-elle d’étendre la notion d’accès restreint non seulement à
des rubriques, mais également à des articles individuels à l’intérieur de rubriques à accès public
Relit le point 8. de la doc ci-dessus : ça fait partie des choses qui sont *possibles* mais pas
prévues dans la TODO... Alors tout est sur la zone, si tu veux apporter ta brique : "you’re
welcome !"...
06/01/2007 22:05
38 sur 38
06/01/2007 22:05

Le plugin accés restreint par groupes - SPIP - contrib

Transcription

Documents pareils

Lorem ipsum pour Porte-Plume

Contrôler l`accès aux contenus dans SPIP 1.9.2 : le plugin « Accès

Gestion et animation d`un site internet sous SPIP et rédaction pour

« SPIP rédacteurs et administrateurs restreints » 13 juin + 14 juin

TD n°8

TP27- Thèmes - 31 place Web

Plugin SPIP Bonux

Plugin Lorem ipsum pour Porte-Plume

Une 403 bientôt sur les routes

Plan de cours CMS SPIP