[spip-dev] sécuriser les "écrasements" de données

Aujourd'hui a été pour nous la première grosse journée d'exploitation de
spip à plusieurs, à quatre en même temps sur les mêmes articles. Pas de
souci majeur, malgré une formation très très courte pour certains. Gros
(mais seul ou presque) point noir, on ne sait jamais trop qui a "sorti" les
textes et risque d'écraser vos modifs.

Je voudrais trouver une solution pour la 1.2 ...

a priori une possibilité est de passer 'maj' dans articles_edit.php3, et de
comparer le maj de la base avec le maj annoncé, et le cas <> échéant,
annoncer "quelqu'un a modifié entre temps, et vous risquez d'écraser ses
modifs: oui ou non ?"

un peu mieux : stocker le nom du dernier modifieur, et dire qui est
"quelqu'un".

encore mieux : stocker aussi le nom du dernier "sorteur", et avertir au
moment où l'on sort un texte que untel l'a déjà sorti il y a xxx jours
minutes sans le remettre... (expirer après 24h?) Dans un cas comme ça, ça
force un peu à coordonner, sans rien bloquer.

Si on part sur la seconde hypothèse, il faut donc

- stocker dernier_sorteur et dernier_rentreur (id_auteur)

- intégrer 'maj' dans articles_edit et comparer dans articles.php3

- difficulté : où stocke-t-on (temporairement) les données si on demande
confirmation? Dans un article id_article="tmp-$id_article-$id_auteur" ??

-- Fil

Gros

(mais seul ou presque) point noir, on ne sait jamais trop qui a "sorti"

les

textes et risque d'écraser vos modifs.

Oui......

a priori une possibilité est de passer 'maj' dans articles_edit.php3, et

de

comparer le maj de la base avec le maj annoncé, et le cas <> échéant,
annoncer "quelqu'un a modifié entre temps, et vous risquez d'écraser ses
modifs: oui ou non ?"

Comment voir les modif puisqu'à priori je suis en train de travailler sur le
texte et qu'il est dans la mémire vive de mon ordi et pas dans la base MySql
? (oui, non?)

un peu mieux : stocker le nom du dernier modifieur, et dire qui est
"quelqu'un".

encore mieux : stocker aussi le nom du dernier "sorteur", et avertir au
moment où l'on sort un texte que untel l'a déjà sorti il y a xxx jours
minutes sans le remettre... (expirer après 24h?) Dans un cas comme ça, ça
force un peu à coordonner, sans rien bloquer.

Il faut éviter d'écraser des modifs d'un texte modifié entre temps mais
comment comparer le texte modifié sauvegardé sur la base Mysql avec le texte
que j'ai rédigé en mémoire vive et que je m'apprête à sauver également?
A moment donné il faut bien que je visualise ces fameuses modif ?

Si tu travailles le texte sous word >> pas de problème , mais alors cela
suppose que tu récupères de temps en temps la dernière "version" pour y
travailler ...
Mais si tu travailles le texte sous SPIP, n'est ce pas plus compliqué ??
comment tu fais alors pour visualiser les deux textes?

Faut il informer le dernier "modifieur" ou tous les auteurs d'un texte qu'il
a été modifié ??
Un message comme celà ?
Le texte #TITRE a été modifié le "date" par "dernier_modifieur
URL_de_l'article

S'il n'y a pas un message comme celui-ci quel est alors l'avantage de la
méthode par rapport au mail?
Il faut donc que celà apporte un "plus".

Maurice

Bonsoir,

Aujourd'hui a été pour nous la première grosse journée
d'exploitation de spip à plusieurs, à quatre en même temps sur les
mêmes articles.

Il me semble qu'on avait parlé de locks à placer sur les articles en
cours d'édition, non ???

on ne sait jamais trop qui a "sorti" les textes et risque d'écraser
vos modifs

"sortir" un texte, c'est entrer en modif ?

-Nicolas

Hello,

Il me semble qu'on avait parlé de locks à placer sur les articles en
cours d'édition, non ???

C'est la solution que je préfère personnellement :wink:

"sortir" un texte, c'est entrer en modif ?

Oui, check out.

a+

> Il me semble qu'on avait parlé de locks à placer sur les articles en
> cours d'édition, non ???

C'est la solution que je préfère personnellement :wink:

Il ne faut pas que ça oblige l'utilisateur à faire une action spéciale,
c'est tout. Maintenant, sur le plan technique je ne sais plus quoi faire...

-- Fil

En réponse à Fil <fil@rezo.net>:

> > Il me semble qu'on avait parlé de locks à placer sur les articles
en
> > cours d'édition, non ???
>
> C'est la solution que je préfère personnellement :wink:

Il ne faut pas que ça oblige l'utilisateur à faire une action
spéciale,
c'est tout. Maintenant, sur le plan technique je ne sais plus quoi
faire...

J'avais déjà posté sur ce sujet. En général, on utilise un timestamp. Si le
timestamp a changé entre le moment ou l'article a été lu, et celui ou
l'utilisateur sauvegarde, l'enregistrement est refusé afin d'éviter l'écrasement.

Les histoires de verrous ça n'amène que des problèmes, surtout à travers le web
qui travaille en mode "stateless" (en HTTP pas de notion de connexion). Que se
passe-t-il si un utilisateur ouvre un article puis ferme son navigateur ??

Que se passe-t-il si j'ouvre un article et que je pars me coucher ou donner le
bain à ma fille sans me déconnecter ? (j'ai l'ADSL :wink: )

Si lorsque je sauvegarde, je reviens sur l'article que j'ai modifié avec le
message "Article modifié depuis que vous l'avez ouvert", j'ai encore la
possibilité de mettre dans le bloc-note me modifs puis de recharger la nouvelle
version de l'article.

Il faut placer des locks à durée de vie limitée, mais établir la liste
des conflits possibles me semble un peu chaud ce soir ...

Le minimum est de ne pas proposer le bouton 'modifier' si un lock est
posé et non expiré.

On en parle demain ? :wink:

-Nicolas

Coucou,

Le débat a déjà eu lieu et chacun a ses opinions sur la question.
Personnellement je pense que le seul système pratique est un verrou
réglable manuellement (y compris sa durée) par celui qui édite l'article.
Une fois ce verrou posé, l'article n'est plus éditable par quelqu'un
d'autre. Cependant, un autre auteur peut choisir de le déverrouiller
au cas où il pense qu'il s'agit d'une erreur ou d'un oubli.

Prévenir après les modifications : comment faire pour fusionner ?
Et si pendant la fusion, un autre auteur fait encore des modifs ?
Pas très commode.... Usine à gaz en perspective, ça ne me plaît pas
du tout ;)) (cf. les contournements de la limite des 32 ko)

Un verrou automatique avec durée préréglée : la durée ne correspond
à rien, elle sera trop petite pour certains et trop grande pour
d'autres.

Ou éventuellement la solution suivante :

encore mieux : stocker aussi le nom du dernier "sorteur", et avertir au
moment où l'on sort un texte que untel l'a déjà sorti il y a xxx jours
minutes sans le remettre... (expirer après 24h?) Dans un cas comme ça, ça
force un peu à coordonner, sans rien bloquer.

a+

Antoine.

PS : chiant ce MailMan qui duplique le [spip-dev] quand il y a des
accents dans le sujet. Ils n'ont toujours pas corrigé le problème ?

Bonjour,

Personnellement je pense que le seul système pratique est un verrou
réglable manuellement (y compris sa durée) par celui qui édite
l'article.

Un verrou manuel, on l'oubli ...

Un verrou automatique avec durée préréglée : la durée ne correspond
à rien, elle sera trop petite pour certains et trop grande pour
d'autres.

La durée de vie n'est utile que si on "oublie" l'article en
modification, ce qui ne doit pas être courant. Dans le cas général, le
verrou est ôté quand on sauve.

Si on veux sauver après que le verrou ait expiré, soit personne n'y a
touché et il n'y a pas de problème, soit on prévient en disant qu'on
ne peut pas sauver les modifs ... ce qui devrait intervenir plus que
rarement dans une équipe bien organisée.

-Nicolas

Un verrou manuel, on l'oubli ...

> Un verrou automatique avec durée préréglée : la durée ne correspond
> à rien, elle sera trop petite pour certains et trop grande pour
> d'autres.

La durée de vie n'est utile que si on "oublie" l'article en
modification, ce qui ne doit pas être courant. Dans le cas général, le

Heu, faudrait savoir : on oublie ou on n'oublie pas ?? On oublie quoi
d'abord ? Personnellement quand je travaille sur un article avec
d'autres personnes, ma plus grande crainte est que quelqu'un vienne
faire des modifs en même temps que moi. Je suis donc conscient du
problème à l'instant t, et ça me soulagerait d'avoir un bouton pour
verrouiller l'article à la main tout en réglant la durée (dix minutes
pour des petites modifs, deux heures si je recopie le texte dans
un fichier texte pour le remodeler profondément...). Un verrou auto
ne me satisfait pas du tout. Quand le verrou est mis, on ne sait
pas si la personne est en train de faire des changements profonds
(revenir dans deux heures), des retouches orthographiques (bouffer
un chocolat en attendant), ou si elle ne va rien changer (elle a
cliqué "comme ça"). Quand le verrou n'est pas mis, on n'est cependant
pas sûr que personne n'est en train de faire des modifs à part soi,
dans un fichier, etc. Ou encore des trucs plus vicieux du genre :
la personne a déverrouillé le texte en faisant valider, mais elle
fait "back" pour rééditer le texte, et si son brouteur garde le
contenu dans le cache, alors le texte ne sera pas reverrouillé.

En plus, avec un verrou manuel, on peut imaginer d'ajouter un
commentaire au verrou, ce qui permet d'informer plus précisément
ses petits camarades (dans uzine, on fait ça dans les forums,
ce qui n'est pas très approprié).

a+

Il n'y a rien de totalement satisfaisant, mais si on cumule deux fonctions :

- un verrou auto de 24 heures, qui saute lors d'un enregistrement, et que
    l'on peut "forcer" ;

- un contrôle de "maj" (timestamp de la dernière édition) au moment du
    retour du fichier, avec, en cas de problème (ie pas le bon "maj" ET
    précédent enregistrement réalisé PAR UN AUTEUR DIFFÉRENT), apparation
    d'un message signalant qui a fait ce dernier enregistrement, +
    possibilité de "voir la version actuelle" + possiibilité d'"écraser".

il me semble qu'on a un truc pas mal, qui répond aux divers besoins, et
reste simple?

-- Fil

J'ai re=E7u =E7a dans une autre liste...
Qu'en est-il ?
Comment cela peut-il =EAtre int=E9gr=E9, a fortiori pour ceux qui ne veulent=
pas bidouiller ?
Merci

J'ai reçu ça dans une autre liste...

  >>>>une info suite au bug de phpnuke à la suite duquel quelques petits malins
ont lancés des scripts robots sur le web pour démolir les sites phpnuke non
protégés.

Qu'en est-il ?

Pour ce que j'ai pu en voir, ce genre de bug n'existe pas dans SPIP

Comment cela peut-il être intégré, a fortiori pour ceux qui ne veulent pas

bidouiller ?
Ca n'est pas si simple. Si vous utilisez simplement SPIP en respectant ce qui
est écrit dans la doc, vous ne craigniez pas grand chose. Encore moins si vous
suivez cette liste. un éventuel bug ne manquerait pas d'être suivi d'un
correctif à appliquer immédiatement.

Par contre, bricoler sur son site avec PHP en mettant n'importe quel script venu
du web sans comprendre exactement comment il fonctionne peut s'avérer dangereux.

Rien de plus, rien de moins...

Bonsoir,

Un verrou manuel, on l'oubli ...
[...]
La durée de vie n'est utile que si on "oublie" l'article

Heu, faudrait savoir : on oublie ou on n'oublie pas ?? On oublie
quoi d'abord ?

Ouais, OK, d'accord, j'ai été flou ... :slight_smile:

Ma crainte avec un verrou manuel, c'est surtout qu'on oublie de le
poser, parce que là ça peut foutre le contenu en l'air.

Si on ou blie de l'enlever, c'est moins grave, ça fait juste perdre du
temps.

avoir un bouton pour verrouiller l'article à la main tout en réglant
la durée

Ca commence à devenir compliqué à utiliser, ça ...

-Nicolas

Il n'y a rien de totalement satisfaisant

Personnellement, pour moi, l'idéal serait un CVS ... :wink:

un verrou auto de 24 heures, qui saute lors d'un enregistrement, et
que l'on peut "forcer"

24h, c'est vraiment très long, donc il sera souvent "forcé".

un contrôle de "maj" [...]

Oui, nécessaire de toute façon.

il me semble qu'on a un truc pas mal, qui répond aux divers besoins,
et reste simple?

Euh ... en gros c'est ce que je proposais, sauf que je voyais plutôt
1h que 24h, non ???

-Nicolas

Salut,

- un verrou auto de 24 heures, qui saute lors d'un enregistrement, et que
    l'on peut "forcer" ;

Je suis vraiment contre le verrou auto. Il n'y a rien de plus déroutant
et énervant que de se voir opposer un message "article verrouillé" si
ce n'est pas le cas.... De plus c'est totalement inefficace, car la durée
ne correspond pas à la réalité :

- si la durée est souvent trop courte, alors le verrou ne sert à rien

- si la durée est souvent trop longue, alors le verrou n'aura plus son
caractère dissuasif (comme les alarmes de voitures qui n'arrêtent pas
de sonner et finissent pas ne plus alarmer personne quand elles hurlent
pour une bonne raison) ; on finit par cliquer "oui, oui, forcer le
verrou" sans même regarder.

Enfin, comme le verrou est automatique, les débutants qui voient
s'afficher un tel message vont être totalement paumés, puisque rien
dans l'interface ne correspond au déclenchement du verrou....

    d'un message signalant qui a fait ce dernier enregistrement, +
    possibilité de "voir la version actuelle" + possiibilité d'"écraser".

Non, c'est usine à gaz ! Il faut quelque chose de _préventif_, pas un
mécanisme pénible quand le logiciel se rend compte après coup que
quelqu'un d'autre a fait des modifs. L'utilisateur de base ne va pas
avoir envie de passer par une procédure de recouvrement/fusion si
des modifs entrent en conflit.

Franchement, par pitié, il faut quelque chose de simple, discret et
qui ne se déclenche pas sans raison.... Et pas de procédure de fusion
de données modifiées : c'est ce que je fais à chaque fois que des modifs
sur SPIP écrasent les miennes, je suis bien placé pour savoir que c'est
pénible comme procédure, et qu'une interface graphique correcte est
quasi impossible ;))

Je propose deux niveaux :

- quand on sort un article, un message signale que l'article a été
ouvert par untel si moins de 3 heures. Effet préventif informatif.

- sur la page d'édition (articles_edit), un lien "placer un verrou" ouvre
une fenêtre où on règle la durée (quatre ou cinq valeurs possibles) et
optionnellement un message informatif (du genre "salut je suis en train
de refaire le troisième chapitre d'après la taxonomie de jean burger" :
ça permet de gagner du temps en évitant d'utiliser les forums pour ça,
en plus le message sera temporaire et non persistant).
Le verrou fait disparaître les boutons "modifier l'article" mais il est
enlevable par n'importe qui ayant les droits d'édition. Effet préventif
et dissuasif, mais sans excès ni risque d'incompréhension.

On peut implémenter l'un, l'autre ou les deux.

a+

Antoine.

Heu, faudrait savoir : on oublie ou on n'oublie pas ?? On oublie quoi
d'abord ? Personnellement quand je travaille sur un article avec
d'autres personnes, ma plus grande crainte est que quelqu'un vienne
faire des modifs en même temps que moi.

Les auteurs présents sur le site sont signalées par SPIP,
c'est aussi un bon indicateur>>

Est ce qu'on pourrait imaginer que quelqu'un soit déclaré comme présent sur
"l'article",

pas présent, ne risque pas de modifier
présent, risque de modifier

Le premier a être présent >> verrouillage
dès qu'il libère >> quelqu'un d'autre peut y travailler

Avec l'indication du dernier à avoir modifié on a presque tout ce qui est
utile et celà reste simple.

MAurice

Bonjour,

Les auteurs présents sur le site sont signalées par SPIP

Uniquement s'ils le souhaitent, attention ...

-Nicolas

Bonjour,

quand on sort un article, un message signale que l'article a été
ouvert par untel si moins de 3 heures. Effet préventif informatif.

OK.

sur la page d'édition (articles_edit), un lien "placer un verrou"
ouvre une fenêtre où on règle la durée (quatre ou cinq valeurs
possibles) et optionnellement un message informatif

Pourquoi pas une combo-list directement sur la page pour éviter les
enchaînements de pages inutiles ?

Le verrou fait disparaître les boutons "modifier l'article"

Oui.

mais il est enlevable par n'importe qui ayant les droits d'édition.

Quel intérêt d'avoir un système de verrou alors ? Il faudrait au moins
un délai minimum pendant lequel on ne peut pas supprimer un verrou.

On peut implémenter l'un, l'autre ou les deux.

Je suis pour les deux.

Et si possible, il faudrait pouvoir laisser l'admin paramétrer les
différentes options.

-Nicolas

@ Nicolas Hoizey (nhoizey@phpheaven.net) :

Je suis pour les deux.

moi aussi (mais il faut coder!)

Et si possible, il faudrait pouvoir laisser l'admin paramétrer les
différentes options.

non, là je suis contre : pas la peine de surcharger les réglages, d'autant
qu'un mauvais réglage sera indétectable - sauf par un pro de spip - et
pénible. Et ce serait autant de questions en plus sur les listes... Il faut
trouver un réglage pas mal, et s'y tenir. Avec l'avantage de garder une
homogénéité entre les différents sites.

-- Fil