[spip-dev] Mise à jour vers dernière version CVS ...

Ca commence bien :

"Mise à niveau de SPIP
Vous avez installé une nouvelle version de SPIP.
Cette nouvelle version nécessite une mise à jour plus complète qu'à
l'accoutumée. Si vous êtes webmestre du site, veuillez effacer le
fichier inc_connect.php3 du répertoire ecrire et reprendre
l'installation afin de mettre à jour vos paramètres de connexion à la
base de données."

Et si je vais sur "groupes.php3", j'ai la fonctionnalité annoncée,
bravo !

Je ne vais pas tester sur le site que j'ai mis à jour, faute de temps,
mais ça me plait déjà !!! :wink:

Par contre, juste pour faire le pénible, pourquoi ne pas généraliser
cette notion de groupe pour gérer d'autres choses que les
mailing-lists, et surtout proposer que les inscriptions à un groupe
soient modérables, voir limitées à un admin. Ainsi, la première pierre
d'une gestion de restrictions d'accès par groupes d'utilisateurs
serait posée ... :wink:

-Nicolas

Par contre, juste pour faire le pénible, pourquoi ne pas généraliser
cette notion de groupe pour gérer d'autres choses que les
mailing-lists

Oui, bien sûr, c'est ce qu'il faut faire. Cette implémentation correspond à
l'idée initiale, qui était d'interfacer spip et Mailman (ou sympa) pour
rapatrier en "interne" la liste waterflash d'uZine. Donc j'étais dans une
problématique "liste de diffusion" - mais en discutant on voit que ça va
évoluer...

et surtout proposer que les inscriptions à un groupe soient modérables,

Comme ça, a priori, je ne vois pas l'intérêt. Que veux-tu faire ? Il y a
déjà une notion de droits dans les "groupes", comment veux-tu l'étendre ?

(Si l'idée est de refaire un gestionnaire complet type sympa, c'est trop
lourd et complexe pour être dans spip, à mon avis il faut trouver ce qu'on
peut faire de *simple* et qui apporte tout de même un vrai service.)

voir limitées à un admin.

Une liste d'une personne, c'est un peu triste non ? :wink:

-- Fil

Hello,

Cette implémentation correspond à l'idée initiale, qui était
d'interfacer spip et Mailman (ou sympa) pour rapatrier en "interne"
la liste waterflash d'uZine. Donc j'étais dans une problématique
"liste de diffusion" - mais en discutant on voit que ça va
évoluer...

OK, cool.

et surtout proposer que les inscriptions à un groupe soient
modérables,

Comme ça, a priori, je ne vois pas l'intérêt. Que veux-tu faire ? Il
y a déjà une notion de droits dans les "groupes", comment veux-tu
l'étendre ?

Ah, j'ai pas encore exploré les groupes, donc je n'ai pas vu cette
notion de droits.

Là, ce que je voulais exprimer, c'est qu'on puisse avoir des listes en
accès libre, en accès modéré, ou dont seul les administrateurs peuvent
modifier les membres.

Les deux premiers cas sont nécessaires pour une gestion de
mailing-lists, et le troisième pour une gestion d'accès restreints.

On peut difficilement autoriser l'auto inscription de n'importe quel
membre à un groupe qui servirait à protéger une partie des contenus,
non ??? :wink:

voir limitées à un admin.

Une liste d'une personne, c'est un peu triste non ? :wink:

Non, non, c'est la faculté d'ajouter des membres à un groupe que je
voulais limiter à un admin, cf ci-dessus ... :stuck_out_tongue:

-Nicolas

On peut difficilement autoriser l'auto inscription de n'importe quel
membre à un groupe qui servirait à protéger une partie des contenus,
non ??? :wink:

De deux choses l'une :
1) ils sont rédacteurs, et tu ne peux pas les empêcher d'accéder aux
   articles dans l'espace privé
2) ils sont visiteurs, et ils n'ont pas d'interface pour s'auto-inscrire.

-- Fil

Hello,

On peut difficilement autoriser l'auto inscription de n'importe
quel membre à un groupe qui servirait à protéger une partie des
contenus, non ??? :wink:

De deux choses l'une :
1) ils sont rédacteurs, et tu ne peux pas les empêcher d'accéder aux
   articles dans l'espace privé

C'est bien ce qui me chagrine. A quoi bon proposer une sécurisation
des contenus côté public, si ces mêmes contenus sont en accès libre
côté back-office ?

2) ils sont visiteurs, et ils n'ont pas d'interface pour
   s'auto-inscrire.

Pour l'inscription à des mailing-lists, ça pourrait être utile.

Bon, quoi qu'il en soit, je pense qu'il faudrait dissocier les aspects
sécurité de la gestion de groupes destinés aux mailing-lists.

-Nicolas

C'est bien ce qui me chagrine. A quoi bon proposer une sécurisation
des contenus côté public, si ces mêmes contenus sont en accès libre
côté back-office ?

C'est pour les gens qui n'ont pas accès au back-office (patate!) ; si tu
fais un site où les gens peuvent s'inscrire à l'espace privé, tu ne peux pas
en même temps vouloir "sécuriser" tes données. Si tu veux sécuriser une
partie des données, et avoir un spip en accès libre d'autre part, il faut
monter deux spip, un point c'est tout.

> 2) ils sont visiteurs, et ils n'ont pas d'interface pour
> s'auto-inscrire.
Pour l'inscription à des mailing-lists, ça pourrait être utile.

Voui, mais c'est une autre étape...

Bon, quoi qu'il en soit, je pense qu'il faudrait dissocier les aspects
sécurité de la gestion de groupes destinés aux mailing-lists.

Tiens, un pas en arrière donc :wink:

-- Fil

Hello,

A quoi bon proposer une sécurisation des contenus côté public, si
ces mêmes contenus sont en accès libre côté back-office ?

C'est pour les gens qui n'ont pas accès au back-office

Oui, mais si (comme dans le cas de je ne sais plus quelle
problématique de clubs de sport) on veut que certaines personnes
puissent publier dans un secteur sans avoir accès, même en lecture, à
un autre, on ne peut pas.

(patate!)

Attention, je vais m'énerver, aussi !!! :stuck_out_tongue:

si tu fais un site où les gens peuvent s'inscrire à l'espace privé,
tu ne peux pas en même temps vouloir "sécuriser" tes données.

Je ne veux pas sécuriser MES données, mais uniquement CERTAINES DE MES
données ... :wink:

Si tu veux sécuriser une partie des données, et avoir un spip en
accès libre d'autre part, il faut monter deux spip, un point c'est
tout.

Et si tu as 12 rubriques à rendre accessible différemment à
différentes personnes, tu montes 12 SPIP ???

il faudrait dissocier les aspects sécurité de la gestion de groupes
destinés aux mailing-lists.

Tiens, un pas en arrière donc :wink:

Pas trop, non, puisque la sécurisation telle que je la conçois (qui
d'autre ?) n'est pas encore prise en charge dans ce que tu as fait, si
je ne m'abuse.

Je ne cherche pas à détruire ce que tu as fait, bien au contraire,
mais à déterminer si gérer ces différents types de groupes au sein
d'un même module est réellement pertinent.

-Nicolas

En réponse à Nicolas Hoizey <nhoizey@php.net>:

Hello,

>> On peut difficilement autoriser l'auto inscription de n'importe
>> quel membre à un groupe qui servirait à protéger une partie des
>> contenus, non ??? :wink:
>
> De deux choses l'une :
> 1) ils sont rédacteurs, et tu ne peux pas les empêcher d'accéder aux
> articles dans l'espace privé

C'est bien ce qui me chagrine. A quoi bon proposer une sécurisation
des contenus côté public, si ces mêmes contenus sont en accès libre
côté back-office ?

+1

> 2) ils sont visiteurs, et ils n'ont pas d'interface pour
> s'auto-inscrire.

Pour l'inscription à des mailing-lists, ça pourrait être utile.

Bon, quoi qu'il en soit, je pense qu'il faudrait dissocier les aspects
sécurité de la gestion de groupes destinés aux mailing-lists.

-Nicolas

--
Nicolas "Brush" HOIZEY
  Free PHP projects http://www.phpheaven.net
Veille tous azimuts http://www.gasteroprod.com
         Clever Age http://www.clever-age.com

_______________________________________________
spip-dev@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-dev
Documentation de SPIP : http://www.uzine.net/spip

From fil@miel.brainstorm.fr Wed Oct 9 10:40:38 2002

Return-Path: <fil@miel.brainstorm.fr>
Received: by miel.brainstorm.fr (Postfix, from userid 1001)
  id D15CD1C893; Wed, 9 Oct 2002 10:40:37 +0200 (CEST)

Alors il faudra utiliser un truc plus complexe et complet : Zope.

Beurk. Zope est plus une plate-forme (ou un framework) de
développement de sites, la surcouche CMS est largement moins bien que
SPIP ...

Je ne veux pas sécuriser MES données, mais uniquement CERTAINES DE
MES données ... :wink:

Ne les mets pas dans SPIP alors.

Bon, je m'attaque à une cause perdue d'avance, là, j'ai
l'impression ... :wink:

[...] la philosophie de cette "sécurisation de données".

... reste à déterminer.

En fait, je crois qu'il faudrait qu'on écrive un document présentant
une "ligne stratégique" pour SPIP et la sécurité

Oui, carrément !!!

Et une ligne stratégique générale, d'ailleurs, pas uniquement sur
l'aspect sécurité.

-Nicolas