Pour mémoire
[22:37:31] thetransporter@jabber.org is Online
[22:33:20] <thetransporter@jabber.org> Bonsoir charles, j'ai pensé a un truc pour éviter le spam de wikini :)
[22:37:55] <charles.nepote> je vais me coucher dans peu mais zyva
[22:38:46] <thetransporter@jabber.org> oki
[22:38:49] <thetransporter@jabber.org> alors j'ai pensé
[22:39:00] <thetransporter@jabber.org> a faire une confirmation par email
[22:39:54] <charles.nepote> pas glop pour un wiki...
[22:40:04] <thetransporter@jabber.org> mmh
[22:40:05] <charles.nepote> plutôt contre productif...
[22:40:10] <thetransporter@jabber.org> ouais
[22:40:26] <thetransporter@jabber.org> mais les utilisateurs enregistrés n'auraient pas cette confirmation
[22:40:45] <charles.nepote> en fait ce qui intéresse les spammeur est bien identifié, contrairement au mail : ce sont des liens
[22:41:11] <thetransporter@jabber.org> ouais ...
[22:41:15] <charles.nepote> oui mais n'importe quel couillon peut faire un robot en 10 minutes pour s'enregistrer
[22:41:25] <thetransporter@jabber.org> avec adrese email ?
[22:41:32] <thetransporter@jabber.org> avec lien de confirmation dans l'email ? :)
[22:41:33] <charles.nepote> je vois plus un filtrage sur le texte entré
[22:42:09] <charles.nepote> il faut encore que l'hébergeur accepte la fonction mail() (pas le cas de free où wikini est très utilisé)
- Free autorise maintenant la fonction mail() avec un quota de 1000 mails par semaine) -- OlivierB
[22:42:23] <thetransporter@jabber.org> et on doit utiliser quoi alors?
[22:43:27] <charles.nepote> on constitue un dictionnaire et si on entre le texte http://www.888888.com/ qui est dans le dictionnaire, l'entrée est refusée (sauf si l'utilisateur a été validé comme sûr (on peut ajouter ça))
[22:44:01] <thetransporter@jabber.org> ha bon ?
[22:44:08] <thetransporter@jabber.org> c deja fonctionnel ce dictionnairE?
[22:44:25] <charles.nepote> en fait ce qui va nous sauver, par rapport aux spam mails qui ne coûtent rien, c'est que les noms de domaines sont payants pour les spammeurs ou leurs commanditaires
[22:45:03] <charles.nepote> chaque nouveau domaine qui n'est pas encore filtré va leur coûter de l'argent
[22:45:31] <thetransporter@jabber.org> mmh
[22:45:33] <charles.nepote> non cette fonction n'est pas en place... il faut discuter de l'implémentation
[22:45:50] <thetransporter@jabber.org> mais comment éviter de salir les pages comme on le vois sur wikini ?
[22:46:29] <charles.nepote> je comprends pas la question ; justement en mettant en place cette solution
[22:46:39] <thetransporter@jabber.org> ah ...
[22:46:56] <charles.nepote> (à mon avis il y a là deux heures de codage une fois qu'on sera d'accord sur la solution)
[22:46:58] <thetransporter@jabber.org> et si le spammeur entre un mot qui n'est pas dans le dictionnaire?
[22:47:17] <charles.nepote> et bien il faut un moyen simple pour l'y ajouter
[22:47:22] <thetransporter@jabber.org> mmmh
[22:47:43] <charles.nepote> et quand il en a marre d'acheter des nouveaux noms de domaines qui ne sont pas dans le dico il arrête
[22:47:47] <thetransporter@jabber.org> allez charles, va dormir, je v pas te retenir :)
[22:48:04] <charles.nepote> je vais publier la convers sur le wiki pour mémoire a+
[22:48:09] <thetransporter@jabber.org> bye
Vous ne pensez quoi vous ? Un email de confirmation pour toute personne anonyme au wiki qui veut publier ?
@+ -TheTransporter-
- Pour ma part, bof... Ça s'éloigne trop du concept du wiki wiki (vite) : s'il faut tapper son adél, puis lire son courriel et cliquer sur un lien de validation à chaque page, c'est encore pire que de s'authentifier une fois pour toute. En plus si c'est une personne anonyme, ça veut dire qu'on ne connaît pas son adél a priori. Il va donc faloir la lui demander et c'est la porte ouverte à l'envoi de pourriel depuis WikiNi ! Bof encore... -- ProgFou
- Justement, l'utilisateur sérieux s'enregistrera, l'utilisateur qui a envie de foutre la merde ne tapera pas son adresse email et ne sauras pas poster. Perso je reste tjs sur ma position, commencer a remplir des blacklist c'est vraiment pas ma facon de faire. Il y aura de tte facon tjs un problème avec les blacklist... soit ca deviendra trop lent, soit le spammeur utilisera un terme qui n'est pas repris dans la blacklist.-TheTransporter-
- Pour cela tu n'as qu'à interdire aux utilisateurs anonymes de modifier les pages, c'est plus simple et cela existe déjà. Le seul bémol c'est qu'actuellement tu ne peux pas vérifier la validité de l'adresse email. Si tu veux envoyer un email pour valider le droit de modification pour un utilisateur anonyme, cela découragera tout ceux qui ne veulent pas s'authentifier mais qui voudraient apporter leur pierre à l'édifice. Dans ce cas là les utilisateurs anonymes ne servent plus à rien ;o) -- OlivierB
- ouais c'est vrai...tu as entierrement raison, je pense pas que la confirmation par email soit une si bonne id finalement... -TheTransporter-
- Pour cela tu n'as qu'à interdire aux utilisateurs anonymes de modifier les pages, c'est plus simple et cela existe déjà. Le seul bémol c'est qu'actuellement tu ne peux pas vérifier la validité de l'adresse email. Si tu veux envoyer un email pour valider le droit de modification pour un utilisateur anonyme, cela découragera tout ceux qui ne veulent pas s'authentifier mais qui voudraient apporter leur pierre à l'édifice. Dans ce cas là les utilisateurs anonymes ne servent plus à rien ;o) -- OlivierB
Par contre, si les utilisateurs enregistrés peuvent mettre des liens vers ces domaines (tel que j'ai pu le lire dans la conversation ci-dessus : ...l'entrée est refusée (sauf si l'utilisateur a été validé comme sûr...) cela pourrait bloquer l'édition par des utilisateurs anonymes, je m'explique :
- un utilisateur connecté modifie une page et ajoute un nom de domaine interdit. Comme il est enregistré et connu, WikiNi autorise l'enregistrement.
- un anonyme modifie la page en question mais au moment de la sauvegarde il aura un message indiquant qu'il y a ne peut pas enregistrer car la page contient un domaine interdit. En effet, WikiNi ne saura pas (ou cela serai trop lourd en temps de traitement car il faudrait comparer les versions) qui a écrit le liens avec le nom de domaine interdit :o(
- Oui, tu as raison pour le coup de l'utilisateur sûr... en revanche il faut des moyens :
- pour permettre à un utilisateur sûr de bloquer certains contenus (les autres utilisateurs devant en être avertis)
- pour permettre à un utilisateur sûr de débloquer certains contenus bloqués par erreur
- de préciser les raisons du blocage à l'utilisateur qui s'est vu refusé du contenu
- pour permettre à l'utilisateur de bonne foi qui s'est vu bloqué certains contenus d'exprimer simplement ses doléances s'il estime que ce n'est pas normal
- .- CharlesNepote
Je vois la solution suivante :
- une variable de configuration : "SpamFilter?" => "ContenusFiltre?"
- ContenuFiltre? est une page du wiki visible seulement par les utilisateurs enregistrés et que seuls quelques utilisateurs peuvent modifier ; elle contient la liste des termes qui sont filtrés, séparés par des espaces
- à chaque enregistrement edit.php contrôle si aucun des termes ne correspond à l'un de ceux compris dans ContenusFiltre?, sauf ceux de la page "ContenusFiltre?"
Si on veut plus de performance, dans un premier temps on peut faire en sorte que le contrôle ne soit pas effectué sur les utilisateurs enregistrés.
-- CharlesNepote
- Le temps + la consommation mémoire (qui est souvent limité comme le temps chez les hébergements partagés comme Free). En fait plus la liste de terme à filtrer sera longue plus le traitement sera long ... surtout sur les grandes pages et on risque de partir en erreur. Autre possibilité la mise en table sql des domaines a exclure puis à chaque lien autre que local detecté on fait un select dans la table pour voir si le domaine s'y trouve -- OlivierB
- Parlons-en, TheTransporter a dessiné un schéma de base de données que j'ai imaginé permettant d'étendre facilement WikiNi à ce genre fonctionnalité :
Il n'y a que la table wikini_triples qui est ajoutée. Elle permet d'enregistrer toutes sortes d'informations complémentaires, permettant ainsi de faire évoluer WikiNi à l'aide d'un modèle générique :
- variable de configuration
- données propres à des actions
- etc.
Prenons l'exemple de la proposition d'OlivierB : à chaque nouveau domaine à exclure, on écrirait dans cette table :
http://wikini.net/wiki/CeWiki, http://wikini.net/vocabulaire/ExcludeUrl, http://www.xxxxxxyyxx.com
ou encore, pour chaque adresse IP pour laquelle on interdirait la modification des pages, on écrirait dans cette table :
http://wikini.net/wiki/CeWiki, http://wikini.net/vocabulaire/ReadOnlyIP, 210.82.76.17
Bien sûr, on peut simplifier en écrivant :
CeWiki, ExcludeUrl, http://www.xxxxxxyyxx.com
mais dans ce cas, on risque de voir apparaître, à long terme, des conflits avec des utilisateurs qui auront personnalisé leur wiki avec des resources et des propriétés de même nom. Sur le web sémantique, pour résoudre le problème de télescopage, on utilise des domaines nominaux qui sont maîtrisés par leurs producteurs. C'est ce que je propose dans la solution 1.
Eventuellement on peut raffiner en utilisant le même modèle de données que l'API RAP, qui est tout prêt pour le web sémantique, cf. :
- http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/
- modèle : http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/database_schema.html
- qui écrit, lit ? (administrateurs ? utilisateurs enregistrés ?)
- comment sais-t-on que de nouveaux triplets sont publiés (DerniersChangements ?)
-- CharlesNepote
Je pense que tu es très clair pour n'importe qui connaissant les concepts XML (en particulier les espaces de noms), mais pour les autres par contre... ;-) Sinon, mis à part le fait que ça fait vraiment boule-de-neige - on va vers la mise en place d'une solution qui va largement au delà du problème de départ - je suis assez pour mettre en place cette solution. Ça débloquera plein d'autres problèmes d'implémentation par la suite, mais il faudra bien réfléchir avant chaque modification du vocabulaire ! -- ProgFou
Oui, tu as tout compris. Ca pourra offrir une solution pour des tas d'autres problèmes ; il faudra veiller à ne pas trop surcharger cette table. S'il y en a dans l'assistance qui ne comprennent pas, je peux détailler. En revanche personne ne s'est prononcé sur le modèle de données à employer :
- simple : resource, property, object
- ou plus complet comme celui de http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/database_schema.html qui a ma préférence est qui est complètement compatible avec le modèle RDF ; mais un tout petit peu plus complexe (je ne suis pas sûr d'ailleurs que l'on soit obligé d'utiliser la table "models").
Sur chongqed.org wiki ils proposent deux listes toutes faites :
On pourrait produire ces listes au format RDF permettant ainsi de partager ces listes entre plusieurs wikis.
Pour le vocabulaire, je vais faire un essai sur la page VocabulaireRDFAntiSpamDiscussions.
-- CharlesNepote
Pour ta question sur qui écrit/supprime, on peut imaginer que les utilisateurs enregistrés puissent écrire de nouvelles adresses ou de nouveaux domaines dans la liste. Par contre pour la suppression, je pense qu'il faut limiter cette possibilité aux administrateurs. Le problème est que pour l'instant il n'y a pas de notion d'administrateur dans WikiNi (Par contre il y a une contrib sur les groupes - à voir si elle n'est pas intéressante pour pouvoir créer des groupes d'utilisateurs dont le groupe admin).
Pour la structure de la table :
- La table pourrait avoir une structure simple. Avantage : développement rapide de la solution.
- Une action pourrait être créée pour générer le format RDF.