Wikini

ProtectionContreLeVandalisme

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-44-222-131-239.compute-1.amazonaws.com
Listons ensemble tout ce qui existe déjà ou ce qui pourrait être mise en oeuvre pour lutter contre ces âneries.

Ce qui existe déjà


1. Spécification des contenus non indexés

La page listant les "révisions" (pages archivées) n'est pas indexée par Google et les liens de cette page ne sont pas suivis par Google (grâce à la directive <meta name="robots" content="noindex, nofollow"/>) ; cette protection fait en sorte que le spammeur ne pourra pas profiter, en théorie, d'un bon google ranking du fait des liens vers son site ; ce système est perfectible ; (cf. PrevenirLIndexationDesRobotsDeRecherche)

2. Faire en sorte qu'il y ait toujours deux entrées dans l'historique


Lors d'attaques de plusieurs de nos Wikini (http://www.nib-jiq.org/ et http://www.videontv.org/wikini/), nous avons pu tester la facilité pour revenir à une page antérieure et donc tout l'intérêt du Wiki pour qu'il soit beaucoup plus rapide pour réparer après une attaque malveillante que pour casser. Nous avons même fait une page guide pour que chaque participant du projet ou même chaque visiteur bien intentionné puisse facilement réparer une page pervertie : http://www.nib-jiq.org/wakka.php?wiki=CommentReparerLesPagesApresUneAttaque
Mais ce n'est pas vrai si la page n'a pas été modifiée depuis plus de trois mois (par exemple les pages expliquant comment utiliser le Wiki sur notre site). Dans ce cas, si la page apparait bien dans l'historique (avec une entrée et la bonne date même si celle-ci est plus ancienne que 3 mois), après une modification bienveillante ou malveillante, il ne reste plus que la dernière version de la page dans l'historique.
Ma proposition serait que l'on ait toujours au moins deux entrées dans l'historique et donc ne supprimer une entrée de plus de trois mois que si il y a eu au moins deux modifications depuis. Comme cela, lorsqu'une page est modifiée de façon malententionnée, il est toujours possible de revenir en arrière, même si la dernière modif date de plus de trois mois. --JeanMichelCornu

La fonctionnalité dans WikiNi depuis le 28/08/2003 (CVS, puis publiée dans 0.4.1) mais elle est sans doute insuffisante : ce qui se passe actuellement, c'est que lorsqu'une page est modifiée, on conserve au minimum l'avant dernière version de la page, quelquesoit son ancienneté.
On a donc le scénario suivant :
Conclusion : si je veux supprimer définitivement le contenu d'une page sans pouvoir revenir en arrière : j'attend que son avant-dernière version ai plus de t jours (ce qui est assez fréquent, il n'y a alors pas à attendre) et je modifie deux fois cette page dans la même journée. J'ai bien conscience que le scénario n'est pas satisfaisant, c'est pourquoi je propose le scénario alternatif ci-dessous.


Ce qui pourrait être mis en oeuvre

(à compléter)
-- CharlesNepote, DavidDelon et GarfieldFr

Protection supplémentaire à partir de l'authentification
Ajouter une sécurité au niveau de l'authentification des utilisateurs. Pour ceux qui le désireraient, n'autoriser l'édition de page qu'aux utilisateurs identifiés (cela existe déjà). Le niveau de protection supplémentaire serai d'ajouter un contrôle de l'adresse e-mail pour l'activation du compte utilisateur (option pour le Wiki) par l'envoi d'un mail d'activation comme l'on trouve dans bon nombre d'autre logiciel (phpbb, spip, ...). Cela permet de responsabiliser les personnes participant au Wiki mais réduit un peu l'esprit Wiki. Cela n'empêchera pas les actes mal intentionnés mais cela pourrait les réduire. -- OlivierB

1. Sur le contenu, en amont

Rappel des idées :

Pour le backlist de certains mots, ou autres filtres, bof bof (solutions 1.1. et 1.2.).
Quand à l'idée de CharlesNepote (1.3.), c'est tout à fait à quoi je pensais, sans arriver à l'exprimer : avoir toujours un version "potable" d'une page, même en cas d'attaque méchante avec proxy et trottinette. Perso j'ai mis en place une sauvegarde hebdomadaire de la base (merci alternc), mais sauf a sauvegarder toutes les heures on n'est pas à l'abri d'une attaque du genre "je fais 20 fois sauver", surtout pour un wiki au contenu politique ou engagé.
--DaOuar

Je pense que la solution 1.3. est vraiment importante car beaucoup d'utilisateur n'ont pas les moyens et les compétences de réaliser des sauvegardes quotidiennes. C'est donc une de mes priorités. Je partage l'avis de DaOuar sur les solutions 1.1. et 1.2. On peut vouloir écrire des cochonceté à dessein, comme par exemple un site de blague cochonnes. Le site de DaOuar, par exemple, n'a pas vocation à faire dans le politiquement correct et c'est heureux.
-- CharlesNepote

2004-04-02
Je viens de regarder le code de WikiNi, il n'y a pas de limite au nombre de versions sauvée pour une page. L'histoire des 20 pages concerne l'affichage du nombre de révision d'une page et c'est un paramètre utilisateur. Donc pourir un WikiNi en enregistrant plus de 20 fois une page ne fonctionne pas. Une révision de page n'est supprimée que si elle est plus vieille que 90 jours (par défaut) et en gardant toujours 2 versions de la page. Donc pour que la page soit irrécupérable, il faudrait que le "mechant" enregistre 2 fois une page pourit et que l'administrateur ne s'en apperçoive que 90 jours plus tard.
--GarfieldFr

1.3 Faire en sorte qu'il y ait toujours dans l'historique une entrée plus ancienne que le délai de purge

Il faudrait mettre en oeuvre le scénario suivant : on conserve obligatoirement la dernière version d'une page ayant dépassée le temps de purge. On aurai donc le scénario suivant :
On assure donc une bonne sécurité de l'ensemble, un malfaisant devant obligatoirement attendre "t" jours avant que son acte malfaisant puisse prendre effet, ce qui laisse largement le temps de s'en apercevoir.
Est-ce que ma proposition est claire ? Qu'en pensez-vous ?
-- CharlesNepote


Et bibi propose son premier jet de code qui à l'air de fonctionner (à vérifier néanmoins car je n'ai testé que les requêtes SQL). Il s'agit uniquement de modifier la fonction PurgePages(), en la simplifiant par ailleurs puisque le processus est maintenant le suivant :
  1. on recherche toutes les versions de pages qui ont dépassé le délai de purge
  2. pour chaque version de page, on supprime toutes les versions qui lui sont plus anciennes : seule reste donc la moins ancienne des versions qui ont dépassé le délai de purge

<?php
    function PurgePages()
    {
        if ($days = $this->GetConfigValue('pages_purge_time'))
        {
            // Selection of every versions older than the page_purge delay 
            $pages = $this->LoadAll("
            select distinct tag, time from ".$this->config['table_prefix']."pages
            where time < date_sub(now(), interval '".mysql_escape_string($days)."' day)
            and latest = 'N' group by tag order by time asc");
            // For each page, delete every version older than the youngest version
            foreach ($pages as $page)
            {
                $this->Query("
                delete from ".$this->config['table_prefix']."pages
                where time < '".mysql_escape_string($page['time'])."'
                and tag = '".mysql_escape_string($page['tag'])."'");
            }
        }
    }

?>

Qu'en pensez-vous ? Il s'agit selon moi d'une nécessité majeure si l'on veut correctement protéger un site sous WikiNi.
J'ajoute que la modification étant triviale et n'apportant que des avantages, on peut facilement imaginer l'intégrer dans la prochaine 0.4.2 (la documentation n'étant pas en place, on peut faire passer cette évolution fonctionnelle primordiale).
-- CharlesNepote
Je ne l'ai pas encore testé, mais sur le principe je suis tout à fait d'accord. -- DavidDelon
Suite à discussions via Jabber avec ProgFou, on a corrigé la requête SQL (merci ProgFou) et on a convenu que le fait de pouvoir conserver n versions n'avait pas un intérêt extraordinaire. -- CharlesNepote
Je vais essayer sur une version locale de wikini.net pour être sûr des résultats. -- CharlesNepote

ProgFou, il y a un problème pour la sélection des pages plus anciennes que le délai de purge (j'ai fixé 60 jours dans mon exemple) :
SELECT distinct tag, time
FROM wikini_pages
WHERE time < date_sub( now( ) , INTERVAL '60'
DAY ) AND latest = 'N'
and tag='WikiniSemantique'
GROUP BY tag
ORDER BY time ASC

me donne :
WikiniSemantique 2004-04-07 18:24:55
alors qu'il existe aussi :
WikiniSemantique 2004-04-12 19:15:02

La bonne requête me paraît donc bien être :
SELECT distinct tag, time
FROM wikini_pages
WHERE time < date_sub( now( ) , INTERVAL '60'
DAY ) AND latest = 'N'
and tag='WikiniSemantique'
ORDER BY time ASC

qui me donne bien :
WikiniSemantique 2004-04-07 18:24:55
WikiniSemantique 2004-04-12 19:15:02
(note que j'ai enlevé le GROUP BY tag) [Ce qui n'est pas correct vis-à-vis du DISTINCT, AMHA. -- ProgFou]

En effet, le but c'est bien de sélectionner toutes les versions d'une page antérieures au délai de purge, puis, pour chacune des ces pages sélectionnées, d'effacer les pages plus anciennes : ainsi on ne conserve qu'une seule page plus ancienne que le délai de purge. J'ai fait des tests grandeur nature avec un backup de wikini.net et ça à l'air de fonctionner parfaitement. Je confirme que cela parait bien fonctionner, mais cela multiplie les requêtes SQL dans le cas d'un gros wiki comme wikini.net : le temps SQL monte à plus de 80%... -- CharlesNepote


Pour mémoire, je reproduis nos discussions via Jabber :


-- CharlesNepote
Le problème de votre GROUP BY est qu'il est fait avant DISTINCT et ORDER BY. Du coup on n'est pas sûr que le time qu'on va obtenir sera le plus petit (il faudrait lui passer un MAX dessus en fait, pour ensuite faire la suppression par comparaison "plus petit ou égal"). A noter que le DISTINCT ne sert normalement plus à rien dès qu'il y a un GROUP BY sur uniquement des champs sélectionnés, puisque le regroupement fera déjà qu'il n'y aura pas deux lignes de résultats dont les champs spécifiés dans la clause GROUP BY seront les mêmes (donc toutes les lignes seront différentes)
Dans le cas présent le DISTINCT est de toute façon inutile puisqu'il ne peut pas exister deux pages dont la combinaison tag-time soit identique (probabilité murphique: il faudrait que deux personnes arrivent à envoyer deux versions d'une même page à des moments tellement proches quand le HanlerEdit? vérifie si la page n'a pas été éditée entretemps pour la deuxième personne, l'insertion de la première ne soit pas encore faite... Ou alors il faut truquer la base de données !) -- LordFarquaad

Comme je l'ai dit dans SuggestionsRapiditeDeTraitement, voici ma version en deux requêtes (nb.: ça doit être faisable en une seule avec MySQL4?):
<?php
        if ($days = $this->GetConfigValue("pages_purge_time")) { // La purge est-elle active ?
            // selection des pages à supprimer: passage obligé car même mysql ne gère pas les delete multi-tables avant la version 4.0
            $wnPages = $this->GetConfigValue('table_prefix') . 'pages';
            $sql = 'SELECT DISTINCT a.id FROM ' . $wnPages . ' a,' . $wnPages . ' b WHERE a.latest = \'N\' AND a.time < date_sub(now(), INTERVAL \'' . addslashes($days) . '\' DAY) AND a.tag = b.tag AND a.time < b.time AND b.time < date_sub(now(), INTERVAL \'' . addslashes($days) . '\' DAY)';
            $ids = $this->LoadAll($sql);
            
            if (count($ids)) { // il y a des pages  supprimer (on pourrait aussi vérifier qu'il y a plus de n pages à supprimer pour ne pas faire de requête s'il y en a peu
                // fabrication de le requête de suppression...
                $sql = 'DELETE FROM ' . $wnPages . ' WHERE id IN (';
                foreach($ids as $key => $line){
                    $sql .= ($key ? ', ':'') . $line['id']; // nb.: le champ id est un int => rien  chapper, pas besoin de guillemets
                }
                $sql .= ')';
                
                // ... et exécution
                $this->Query($sql);
            }
        }
?>
(code non testé, je n'ai d'ailleurs pas de base de données suffisemment grosse pour le faire, mais j'ai confiance)
NB. au sujet des performances: MySQL optimise les DISTINCT de sorte que quand elle (il ? lol Non, une fille c'est mieux entre le PhP et l'Apache :D) aura trouvé un a.id, elle arrêtera de chercher dans la table b, puisque les champs de la table b ne nous intéressent pas.
-- LordFarquaad


Ok. Ca a l'air de fonctionner parfaitement d'après mes premiers tests et c'est en effet plutôt rapide tant qu'il n'y a pas des dizaines de pages à purger. Je nous laisse encore un petit délai de réflexion (mettons jusqu'à mercredi 12) du fait qu'il s'agit d'une modification touchant une fonction sensible. Cela dit, un grand bravo LordFarquaad pour tes résultats qui dépassent mes espérences : non seulement on gagne en fiabilité (puisque qu'on conserve désormais la dernière page arrivée en période de purge) mais également en performance ! Pour vérifier avec certitude que cela fonctionne bien, j'envisage de l'implémenter quelques temps sur wikini.net pour en observer le fonctionnement. Qu'en pensez-vous tous ? -- CharlesNepote

Optimisation : calcul de la date de purge via php

Une optimisation possible (et certainement bonne car elle éviterait à MySQL certains calculs) consisterait à construire la date de purge via php au préalable. Je sais que MySQL évalue une seule fois le NOW() pour toute la requête, mais je suppose qu'à chaque nouvelle entrée dans la table a ou la table b, elle recalcule le DATE_SUB et le INTERVAL, malgré que ce soit toujours la même valeur... -- LordFarquaad

Optimisation : purge par paquet

Avec le principe que tu utilises, pour optimiser la fonction on pourait purger par paquet : par exemple : 1/10ème par 1/10ème évitant un long temps d'attente pour celui qui "tombe" sur la purge. Ton idée de valeur en deça de laquelle il ne faut pas purger est aussi à retenir. -- CharlesNepote

Je ne pense pas que ce soit si intéressant de ne purgrer qu'une fraction étant donné que le plus lent est la requête de sélection. -- LordFarquaad

Optimisation : purge conditionnelle

Par contre ce qui pourrait être intéressant c'est une purge conditionnelle : dans certains cas on n'effectue pas la suppression car le script "estime" que ça n'en vaut pas le coup (par exemple faire une requête pour supprimer moins de x pages ne serait pas assez intéressant)
En fait je pensais principalement au fait de ne pas purger quand il y a trop peu de pages à supprimer (avec une nombre minimum choisi par l'utilisateur), mais l'idéal serait probablement une estimation plus complexe basée sur différentes choses:
En fait ces facteurs pourraient influencer la probabilité de lancer une purge. Je vois bien une probabilité de ce genre:
Ensuite, après la sélection des pages à supprimer il ne reste plus qu'à vérifier combien il y en a, et ne pas le faire s'il y en a peu. -- LordFarquaad

Optimisation : purge conditionnée par la date de la dernière purge

Ce qui serait bien c'est de passer certains paramètres de configuration dans la base de données, comme ça on pourrait aussi vérifier d'abord la date de la dernière purge... -- LordFarquaad
Il y a deux possibilités en fait:
-- LordFarquaad

On en revient encore et encore au même problème : la possibilité d'intégrer des données de configuration dans la base de manière souple. Et la encore, un stockage sous la forme de triplets (RDF ou éventuellement notre sauce (mais je préfèrerai RDF)) permettrai d'avoir une grande souplesse. Exemple pour résoudre ce présent problème (j'ai utilisé la notation N-Triples qui est très proche de ce qui serait stocké dans la base) :
<http://www.wikini.net/wakka.php?wiki=CeWiki> <http://wikini.net/vocabulaire/DernierePurge> "2005-01-15" .
-- CharlesNepote

Ah oui c'est sûr, ce serait une optimisation à faire une fois que cette décision sera prise, en attendant on peut se contenter de ne pas faire la requête de suppression s'il y a trop peu de pages à supprimer. Il faut voir le gain:
-- LordFarquaad

1.4 Ne jamais purger la dernière version enregistrée par le propriétaire de la page


31/03/2004 - Encore une autre solution qui pourrait être mise en oeuvre pour pallier à la limite de l'historique des révisions d'une page (quelque soit la profondeur de cet historique) : Ne jamais purger la dernière révision enregistrée par le propriétaire de la page !
Pour toutes ces raisons, la solution que je privilégierai serait d'ajouter un marqueur de sauvegarde (par un attribut dans la base) à une révision de l'historique (solution 2.1 donc), car cela conjugue une facilité d'emploi pour les utilisateurs avec une charge de traitements raisonnables pour déterminer quelle révision est à conserver.
-- Yxorp

Lorsque le propriétaire dédits pages concernées s'identifie il aura accée à une version de celle-ci que les "simple vandal" ne peuvent n'auront pas connaissance --SloYvY

-- Moi aussi je pense qu'il vaut mieux une solution basée sur la facilité de reconstruction, comme ce que propose CharlesNepote, et pour intégrer l'idée de la dernière version du propriétaire, il suffirait de conserver les DEUX dernières révisions, celle du propriétaires et/ou une entrée plus ancienne que le délai de purge. Qu'est-ce qu'il faut modifier en PHP et où ? -- Bastien

Pour chaque page, on pourrait garder toutes les révisions suivant la dernière révision par le propriétaire de la page, cette dernière faisant donc autorité. Ainsi, en cas de vandalisme, il suffirait d'effacer toutes les révisions faites depuis l'adresse du vandal, tout simplement. Attention cependant aux gens qui passeraient à plusieurs derrière un proxy... On pourrait améliorer le filtre d'effacement par une date de début vandalisme. -- ProgFou

2. Sur l'accès, en amont



2.1 Passer le wiki en lecture seule

Cf. BasculerUnWikiEnLectureSeule

2.2 filtrer les noms de machine


Problème : Il n'y a pas de limite dans le nombre d'édition d'une page pour une IP (testé sur WikiNi 0.1.1.0.3)
Cela peux entrainer quelqu'un de mal intentionné à détruire un wiki. Il suffit de sauver 20 fois une page vide pour que la récupération de la page soit impossible.
Solution ? A mon avis, quand une IP différente à celle de la derniere modification sauve une page plusieurs fois, il faudrait que la 20eme modification reste celle qui à une IP autre (pas facile a expliquer) : maichan.com veux detruire une page, il sauve 20 fois, mais wikini est malin, il remarque que les 20 derniers changements proviennent de la même IP, et garde le dernier changement fait avec une IP différente.
Ou alors, limiter à 19 édition par IP...
Est-ce grave docteur ?
--DaOuar

Non. Il y a beaucoup d'autres possibilités pour pourrir un Wiki en général (et donc WikiNi en particulier) et la limitation de modification par l'adresse IP ne sert pas à grand chose pour un "méchant"... Il est assez facile de fabriquer un petit robot pour saturer toutes les pages et faire un vrai merdier. Tous les concepteurs de Wiki en sont conscients. Vraiment, la seule méthode efficace c'est la sauvegarde régulière de la base (au moins quotidiennement). Et ce type de problème est vraiment ultra-rarissime. On peut toujours y réfléchir mais il ne faut pas fantasmer sur les solutions... Je suggère que tu déplaces ta proposition dans VosSuggestions, car il ne s'agit pas d'un bogue.
-- CharlesNepote

Exact, ce n'est pas un bug. Mais une limitation par IP, ou mieux garder la derniere modif avec un IP différent pourait décourager les 'maichan" du dimanche. Si il faut se déconnecter, ou utiliser un proxy, il faut vraiment avoir envie de faire chier (d'ailleur je vais aller faire une sauvegarde de notre base de donnée, tiens :) [ il existe un programme multi-poxy qui permet de changer de proxy pour chaque requête HTTP ou pour chaque site. Cela permet d'être anonyme car l'IP du client est celui du proxy qui change à chaque requête! --GarfieldFr]
--DaOuar

2.2.1

Vu qu'il est revenu à la charge aujourd'hui (lendemain) voici un petit script à mettre dans wakka.php pour lutter contre CE spammeur, mais bien sûr c'est un patch temporaire, en attendant la tempête !!
tout au debut de wakka.php :
// check for the motherfucker/son of a bitch with a sura.ru domain
// get infos from user
$whoisit = strtolower(gethostbyaddr($_SERVER['REMOTE_ADDR']));
if ( strpos($whoisit,"sura.ru") ) {
	header("Location:http://www.google.com");
	exit;	
}

-- laurent

2.2.3.

Ca permettrait au "plaisantin" (disont vandale) d'accéder uniquement à cette page en lecture (dès qu'il arrive il est renvoyé dessus). Avec un redirect en 5 s vers google (pour lui...). Si besoin les gens intéressés pourraient signaler (par un moyen à trouver) qu'ils souhaiteraient sortir de la blacklist... Je privilégie le mode wiki qui permettrait d'intervenir sans accès au serveur (contact admin...). Sur wikipedia je crois me rappeler qu'il y a un mode de blacklist, je ne sais plus trop comment il est implémenté (au niveau fonctionnel j'entends). -- BenoitAudouard 20040330


2.3 filtrer les "Références"



2.4 la possibilité de passer en validation manuelle

Parfois dans mes web-promenades, je m'enregistre, et pour ce faire je suis obligé de lire une image de quelques chiffres, illisibles par un robot. Pourquoi ne pas utiliser ce procédé ? -- FidelioEspoir



30/03/2004 - Conscient des possibilités de vandalisme potentiel sur un Wiki, et dans le cadre d'un site communautaire francophone sur Linux Slackware, nous avons choisi de n'autoriser l'édition des pages qu'aux membres authentifiés du site. Cela a bien évidemment nécessité la modification du code de WikiNi pour intégrer la gestion des comptes utilisateurs avec celle du site. Après tout, notre Wiki est un espace de travail pour les contributions des membres, donc cela ne va pas dans le sens contraire de "l'esprit Wiki" dans ce cadre précis. Bien évidemment, cela n'empêche pas qu'une personne créée un compte pour polluer le Wiki, mais ça reste une barrière somme toute acceptable pour empêcher les abus et ne pas gêner les membres actifs qui souhaitent contribuer. Ce qui serait souhaitable, surtout avec la démocratisation des Wikis et la recherche des nouvelles techniques de "spam référenceurs", ce serait de :
-- LiNuCe


3.



3.1 me paraît également un excellent outil ! -- CharlesNepote

Pouvoir éliminer les ajouts d'une IP précises serait un grand plus pour "dépourrir" un wiki touché. --DaOuar
-- Oui IP précise, mais les "anonymous" passant par des sites ad hoc ? tu ne pourras les interdire -- Je ne crois plus aux lignes Magino...mais au plan de reconstruction facile ....--FidelioEspoir


Ailleurs


une idée de PhpWiki :
I also wish to block robots to dig through diff, info, etc pages from my wiki sites, and currently I only check their user agents. However, instead of sending status 302 back to the bots, I use a little SEO trick called cloaking, i.e. sending back different contents when I detect a bot. For example, in my template/browse.html, I don't include the toolbar at bottom (which has all the links to different actions) when a bot is requesting that page. There are other cloaking tricks you can do to avoid stupid search engine bots (or to grab their attentions), but not all cloaking usage are approved by the seach engine companies. --ScottYang?
-> Avoir une liste d'ip et de nom de domaines dans une blacklist, c'est toujours utile. Il n'affiche pas la barre des outils et sans doute n'accepte aucune requete POST de la part d'ip ou nom de domaines (NS lookup) dans la blacklist.

-- Propos d'un non-informaticien : La défense a plusieurs niveaux : la page, un ensemble de page, le wiki affiché, la base,..le serveur...la brevètabilité...
Mais ne jamais oublier qu'une défense isolée est aussi une arme : si je puis systématiquement réécrire un texte, je peux systématiquement écrire "*?§€$$*" l'injure de toute à l'heure.

Une défense efficace = la wiki-défense ou wiki-immunité :
-- un non-informaticien courageux mais pas php-téméraire, pas encore ! ;-) FidelioEspoir

Solution à base d'action

Mettre en place une action dans le genre {{denied ip="192.168.0.1;142.254.169.152"}} où dès que cette ip se connectera il recuperrera un beau die ("vous n'êtes plus autorisé à modifier cette page"); l'avantage de cette solution est d'être simple et rapide et ne nécessiste pas de modification. -- Crazy pops


Historique des débats

(j'ai viré tout ce qui n'est pas relatif au débat)

On peux par contre cumumler les idées de GarfieldFr et DavidDelon, à savoir une admin qui permet de supprimer les pages d'une IP donnée (3.1.), et de lui empécher l'accès au site (2.2.) (quoique en général ces attaques de spam sont ponctuelles, le malotru se contente de polluer tous les wiki qu'il trouve...)
En fait, on reparle d'une InterfaceDAdministrationWikiNi --DaOuar

D'autant que les pages n'apparaitraient pas dans les DerniersChangements. C'est aussi une possibilité de censure qui est donné à l'administrateur ; il faut bien réfléchir.
2.2.3, 2.2.4 et 2.3 me paraissent aussi intéressantes.
-- CharlesNepote

Sauvegarde Page type

Bonjour, d'abord juste un petit bravo pour Wikini qui est vraiment super. Comme je suis nouveau je ne suis pas sûr exactement de l'endroit où écrire cela; si je me trompe excusez-moi. Voilà pour le moment je teste wikini donc la sécurité n'est pas la priorité, toutefois lorsque je rendrai publique mon site je me rends compte qu'il y a une possibilité de vandalisme.

Et je me rends compte qu'il manque (enfin je crois que cela n'existe pas encore) une solution simple de récupération de donnée: pouvoir faire une sauvegarde par l'administrateur d'une page considérée comme correcte.
Petite explication:

Un tel système permet de garder une version de page jugée correcte tout en laissant la possibilté de modification.
De plus cela permet de simplifier le système de purge: si les pages ont plus de 3 mois, elles sont effacées sauf la dernière version et la version "page type".
Même pour les personnes faisant des sauvegardes régulières de leur base de données, cela permet de restaurer facilement et rapidement une page.

Toutefois cela implique la notion d'administrateur ou de groupe d'administration.
Pour avoir accès aux fonctions d'administrations (restauration intégrale de toutes lespages), un panneau d'administration doit être créé.

Voilà j'espère avoir été clair. Je n'ai pas trop réfléchi sur la question, donc cette solution peut sûrement être améliorée, mais je pense qu'elle présente un bon début de piste.
-- Animemint


La page devenait trop longue et commençait à s'effacer au fur et à mesure qu'on l'éditait, j'ai coupé cette partie:
ProtectionContreLeVandalismeFiltresAntiSpam
(j'espère que c'est le seul cas sur wikini.net car c'est vraiment embêtant cette histoire quand on n'y preête pas attention, il faudrait resortir la discussion à ce sujet mais je ne sais plus où elle se toruvait... peut-être dans les suggestions ou un truc du genre -- LordFarquaad)

Confirmation anti-robot

Personellement je serait pour l'ajout d'une image "anti robots" qui affiche un texte qu'il faut retaper pour validation lors de l'édition de pages quand on est pas propriétaire de la page ou si la page n'existe pas encore... -- MagicalTux
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2013-04-09 23:44:12 :: Propriétaire : WikiAdmin :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)