Hallo,
ich würde gerne für eine Art Gästebuch/Forum die SPIP-eigenen Foren nutzen. Jetzt wollte ich mal in die Runde fragen, wie es da mit dem SPAM-Schutz aussieht. Hat da jemand schon (positive|negative) Erfahrungen mit gemacht? Oder gibt es da irgendwelche nützlichen Plugins? (Es wird SPIP 1.9.1 genutzt)
viele Grüße
Heiko
Hallo Heiko,
SPIP hat sich bisher als relativ immun gegen SPAM erwiesen. Durch das dreistufige Überprüfungssystem kann man sich gut gegenAtacken schützen, wenn sie einen denn mal treffen sollten.
1. Zunächst kann man Foren "offen" lassen, d.h. jeder kann posten und alle Beiträge werden sofort angezeigt. Die Eingabeformulare per Robot zu befüllen ist wohl relativ umständlich. Das ist meines Wissens noch nicht vorgekommen. Da man jederzeit per Mail über neue Beiträge informiert wird, kann man Datenmüll komfortabel löschen. Bei sowieso.de fallen ab und zu ganze Schulklassen über uns her und posten innerhalb einer Stunde dutzende von unflätigen Anzüglichkeiten, die dann von uns sofort weggeklickt werden. Wenn wir im Urlaub sind, werden die Foren vorübergehend abgeschaltet.
2. Die zweite Stufe, die eine Anmeldung mit Benutzername und Paßwort beim System voraussetzt, bremst Robots und und Individualspammer sehr schön aus.
3. Spätestens in dem Augenblick, wenn Du die obligatorische Freigabe von Forumsbeiträgen durch einen Administrator aktivierst, sind die Spammer ganz draußen.
Falls die eingebauten Features nicht reichen, könnte man mit SPIP >= 1.9 ein Plugin entwickeln, das Posten von Beiträgen erst nach Eingabe eines als Grafik angezeigten Zufallscodes erlaubt. Da man sämtliche Verhaltensweisen von SPIP mit eigenen Funktionen "überladen" kann und SPIP inzwischen sehr leistungsfähige Werkzeuge zur Grafikbearbeitung enthält, sollte jeder angehende PHP-Programmierer solch ein Plugin schreiben können.
Alle Formulare von SPIP sind jetzt als "Skelett" realisiert, so daß Du auch andere Wege der Eingabeprüfung realisieren kannst. Wie wäre es mit einem Javascript-Formular, das Bilder aus der SPIP-Datenbank verwendet, um zu überprüfen, ob der Poster ein Mensch ist. Etwa so: Thumbnail zeigt Eiffelturm, und Post muß mit Begriff "Eiffelturm" beginnen 
Ich selber habe einmal Probleme mit SPAM gehabt, da ein russischer Robot ein PHPBB auf dem Server geknackt hatte und so die Datenbank manipulieren konnte. Mein SPIP lief auf der selben Datenbank, so daß ich Inkonsistenzen befürchten mußte. Nach Entfernen von PHPBB habe ich deshalb die SPIP-Artikel durch Einspielen einer Sicherungskopie wieder in einen zuverlässigen Zustand gebracht.
In der Vergangenheit gab es eine Anfälligkeit für XSS-Atacken und ein Sicherheitsloch in Version 1.6. Beide Themen wurden innerhalb weniger Stunden bearbeitet und Updates bzw. Patches bereitgestellt. Diese Erfahrungen haben dazu beigetragen, daß SPIP mit Version 1.9 eine neue Architektur bekommen hat, die Angriffe dadurch erschwert, daß alle Funktionen über ein zentrales Skript aufgerufen werden und die Gültigkeit von Funktionen und Daten zur Laufzeit überprüft werden kann.
Wenn Du dazu mehr erfahren möchtest, frage ich gerne in der Entwicklerliste nach dem neuesten Stand.
Grusz, klaus++
Heiko schrieb:
Hallo,
ich würde gerne für eine Art Gästebuch/Forum die SPIP-eigenen Foren nutzen. Jetzt wollte ich mal in die Runde fragen, wie es da mit dem SPAM-Schutz aussieht. Hat da jemand schon (positive|negative) Erfahrungen mit gemacht? Oder gibt es da irgendwelche nützlichen Plugins? (Es wird SPIP 1.9.1 genutzt)
viele Grüße
Heiko
_______________________________________________
Spip-de@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-de
Auf einem Server macht es oft Sinn, dass man nur eine Software installiert, und mehrere Installationen bedient.
Bei Typo3 sind die User-Installationen mit der Installation nur verlinkt.
Ich meinte mal irgendwo einen Vorschlag gelesen zu haben, wie man das für SPIP machen kann.
Finde ihn leider grad nicht mehr.
Gruss
Patrick
<Ich meinte mal irgendwo einen Vorschlag gelesen zu haben, wie man das für SPIP machen kann.
<Finde ihn leider grad nicht mehr.
Ich hab's jetzt doch noch gefunden, aber nicht über google, sondern über die Site-Map von spip-contrib:-)
Gruss
Patrick
Für mich stellt sich v.a. die Frage, ob dann die Updates einfach gemacht werden können.
Kann ja immer auch sein, dass eine Installation, dann nicht mehr funkioniert.
sieht mir nicht sooo einfach aus...
Gruss
Patrick
Hallo Patrick,
es gibt zwei unterschiedliche Methoden, mehrere SPIP-Installationen auf einem Server zu betreiben:
1. klassisch - mehrere SPIP in unterschiedlichen Verzeichnissen mit mes_options
Du kannst Deine SPIPs in mehrere Verzeichnisse auf dem selben Server kopieren. Wenn Du unterschiedliche Datenbanken verwenden willst, mußt Du in die Datei ecrire/mes_options.php (bzw php3 bis SPIP 1.8n, falls nicht vorhanden, muss mes_options.* angelegt werden) folgende Zeilen einfügen:
$table_prefix = "meinprefix";
$cookie_prefix = "meinprefix";
Damit unterscheidet SPIP die verschiedenen Installationen in der Datenbank. Pro Installation ist ein unterschiedliches Prefix erforderlich.
2. professionell für Provider - eine einzige SPIP-Installation bedient mehrere (Kunden) Websites mit individuellem Content
Zu diesem komplexen Thema kenn ich folgende Quellen:
http://www.spip-contrib.net/Un-noyau-SPIP-1-9-plusieurs-sites
http://trac.rezo.net/trac/spip/ticket/186 (eigentlich eine Fehlerbeschreibung, gibt Elemente zur Vorgehensweise)
Für SPIP 1.72:
http://www.spip-contrib.net/Spip-Clone-Gestion-de-sites-en
Für SPIP 1.6:
http://www.spip-contrib.net/MultiSpip-creez-des-sites-Spip-en
Die Infos sind auf Französisch. Wenn Bedarf besteht, können wir eine Beispielinstallation zusammen dokumentieren. Dabei dürfen wir auf schnelle Unterstützung durch die französischen Kollegen zählen.
Grusz, klaus++
Patrick Ogay schrieb:
<Ich meinte mal irgendwo einen Vorschlag gelesen zu haben, wie man das für SPIP machen kann.
<Finde ihn leider grad nicht mehr.Ich hab's jetzt doch noch gefunden, aber nicht über google, sondern über die Site-Map von spip-contrib:-)
Gruss
Patrick_______________________________________________
Spip-de@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-de
> professionell für Provider - eine einzige SPIP-Installation bedient mehrere (Kunden) Websites mit individuellem Content
>Zu diesem komplexen Thema kenn ich folgende Quellen:
>http://www.spip-contrib.net/Un-noyau-SPIP-1-9-plusieurs-sites
>http://trac.rezo.net/trac/spip/ticket/186 (eigentlich eine Fehlerbeschreibung, gibt Elemente zur Vorgehensweise)
>Für SPIP 1.72:
>http://www.spip-contrib.net/Spip-Clone-Gestion-de-sites-en
>Für SPIP 1.6:
>http://www.spip-contrib.net/MultiSpip-creez-des-sites-Spip-en
Ich möchte in der Tat auf einem V-Server mit einem Kern mehrere unabhängige Installationen betreiben.
Die Datenbanken sind nicht das Problem, da Datenbank und Tabellenpräfix beliebig gewählt werden können, also völlig unabhänig von der SPIP-Installation sind.
Probleme können aber auftauchen, wenn man eine einzelne Installation upgraden will, weil die DBs sich je nach Release ja verändern können.
Ich werd's mir genau anschauen, wenn ich Zeit habe.
viele Grüsse
und gutes Wochende
Patrick
Hallo Patrick,
die Updates stellen mit SPIP >= 1.9 kein Problem mehr dar, da Du Modifikationen an SPIP selber durch Überladen der Fuktionen erreichst. Die geänderten Funktionen speicherst Du in Dateien, die außerhalb der Pfade des "Kern"-SPIP liegen, so daß sie bei einem Update nicht überschrieben werden.
Weiterhin erforderlich ist es natürlich, vor einem Update die Kompatibilität von Plugins und individuellen Anpassungen zu testen. Die neue Architektur der Versionen ab 1.9 wurde besonders aus dem Grund eingeführt, diese Fragen systematisch prüfen zu können. Wenn die Tests erfolgreich sind, genügt es, die alten Sourcen durch die neuen zu ersetzen. Wie immer liegt die Krux in einer genauen Dokumentation aller Funktionen und Erweiterungen
Welche Fragen stellen sich Dir denn speziell?
grusz, klaus++
Patrick Ogay schrieb:
Für mich stellt sich v.a. die Frage, ob dann die Updates einfach gemacht werden können.
Kann ja immer auch sein, dass eine Installation, dann nicht mehr funkioniert.sieht mir nicht sooo einfach aus...
Gruss
Patrick_______________________________________________
Spip-de@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-de
Hallo Patrick,
Ich möchte in der Tat auf einem V-Server mit einem Kern mehrere unabhängige Installationen betreiben.
Sehr sinnvoll, gerade auf einem Vserver, da Du sehr viel Arbeitsspeicher und Plattenplatz sparst.
Die Datenbanken sind nicht das Problem, da Datenbank und Tabellenpräfix beliebig gewählt werden können, also völlig unabhänig von der SPIP-Installation sind.
Wenn Du separate "Kunden", "Webs", oder wie auch immer das in Deinem Servermanager heißt, anlegst, bietet es sich an, pro SPIP eine Datenbank einzurichten. Mir erscheint das übersichtlicher, als eine einzige Datenbank mit diversen Tabellen, die sich nur durch ihr Prefix unterscheiden, zu nutzen. Allein für ein summarisches Backup bietet die Methode mit den Namenszusätzen einen Vorteil. Andererseits nervt UNIX/LINUX nicht wie Windows mit seinen Dateisperren, so daß Du im laufenden Betrieb einen Snapshot des Datenverzeichnisses Deines MySQL-Servers machen kannst.
Probleme können aber auftauchen, wenn man eine einzelne Installation upgraden will, weil die DBs sich je nach Release ja verändern können.
Ob das zu Komplikationen führt, hängt davon ab, wie weit Du die Datenstruktur von SPIP mit eigenen Modulen erweiterst oder sogar Daten mit eigenen Plugins in die Standardtabellen schreibst. Die wichtigesten Tabellen und Felder sind seit Beginn von SPIP im wesentlichen unverändert: spip_articles, spip_auteurs etc. Die Datenstrukturen wurden überarbeitet, um weitere Funktionen zu ermöglichen (z.B. die Mehrsprachigkeit) und um Relationen herzustellen. Was sich auch massiv weiterentwickelt hat, ist die Statistik, die jetzt eine andere Datenstruktur erhalten hat. Solange Du z.B. nur eigene Tabellenspalten (etwa für das Geburtsdatum eines Autors in spip_auteurs) oder Tabellen (spip_meinetabelle) hinzugefügt hast sehe ich kaum Probleme. Solche Erweiterungen werden bereits vom neuen Backup-System mit gesichert und zurückgespielt. Komplizierter könnte es werden, wenn Du zusätzliche n-n-Relationen eingeführt haben solltest. Ob so etwas ein Update übersteht müßte man ausprobieren und mit den Entwicklern klären.
Aber auch dafür ist ein "Provider-SPIP" hilfreich, da man nur einmal gründlich zu testen braucht.
Good night and good luck,
klaus++
Es geht fast, aber leider nocht nicht ganz:
Also:
1)
ich hab einem
* virtuellen Host definiert,
* und darin ein alias auf die SPIP-Installation
* und mache ein Rewrite auf die eigentliche Installation
soweit geht funkionert das, man arbeitet mir der eigentlichen SPIP-Installation, auch einloggen funkionert.
Eine Art, eine kurze URL zu erzeugen:
z.B. http://comores.ch/spip.php?article26 (nur so erreichbar, wenn Eintrag im Hostsfile)
statt: http://80.74.143.185/spip/spip.php?article26
2)
Jetzt versuche ich in mes_options.php die Dateien "richtigzustellen".
Da hab ich jetzt unterschiedlichste Merkwürdigkeiten.
http://www.comores.ch/spip.php?rubrique6 (mit dem korrekten Layout, und mit Daten)
Aber ich komme nicht ins Redaktionsmenü, wie wenn die Verbindung zur DB dann nicht klappt.
<?php
if ($_SERVER["SERVER_NAME"] == "www.comores.ch") {
# echo ($_SERVER["SERVER_NAME"]);
# echo("$f-{$r[1]}");
$cookie_prefix = $table_prefix = "spip";
$f = "/var/www/comores/"; define('_SPIP_PATH', '/' . $table_prefix . '/:./:dist/:formulaires/:ecrire/');
define('_DIR_IMG', $f.'IMG/');
define('_DIR_DOC', _DIR_IMG);
define('_DIR_CACHE', $f.'CACHE/');
define('_DIR_SESSIONS', $f.'data/');
define('_DIR_TRANSFERT', $f.'upload');
define('_FILE_CONNECT_INS', $f.'inc_connect');
# echo (_FILE_CONNECT_INS);
$GLOBALS['dossier_squelettes'] = $f.'squelettes'; /* ok */
if (is_readable($f .= 'mes_options.php')) { echo("$f"); /* Pfad scheint o.k. */
include($f); /* wird nicht ausgeführt, hat ein Fehler drinnen.
}
#echo($_SERVER['REQUEST_URI']);
#echo("{$_SERVER['REQUEST_URI']}-$r[1]-$f");
}
$forcer_lang=true;
?>
siehe auch:
http://www.ddy.ch/pm/laden/pm.wiki/Products/SpipMultInst
Der Ansatz, den ich im anderen Mail beschrieben hatte, ist völlig korrekt (nach der Beschreibung in contrib. aber eine URL fest codiert).
Ich konnte eine neue Installation machen, mit einem anderen DB_prefix.
inc_connect wird lokal erstellt, mes_option ruft das lokale mes_option auf: no Probs.
Ich hab die DB kontrolliert, User wurde erstellt.
Nur kann ich mich nicht einloggen. Komischerweise kann ich mich auch nicht einloggen, wenn ich mit dem anderen DB-Prefix arbeite (wo der User garantiert richtig ist:-)
Interessant ist, dass das System motzt, wenn man einen ungültigen User eingibt (also kommt das System doch auf eine DB), aber man kommt mit dem gültigen User nicht *ins" Redaktonsmenü, sondern zu einer weiteren Login Maske.
Ich glaube, ich muss in den Code steigen...
Es wäre zu schön gewesen, wenn das jetzt geklappt hätte:-)
Gruss
Patrick
Hallo Patrick,
die Methode, die Du beschreibts verwende ich seit längerem ohne jedes Problem. Mit welcher Version von SPIP testest Du das denn gerade?
klaus++
Patrick Ogay schrieb:
Der Ansatz, den ich im anderen Mail beschrieben hatte, ist völlig korrekt (nach der Beschreibung in contrib. aber eine URL fest codiert).
Ich konnte eine neue Installation machen, mit einem anderen DB_prefix.
inc_connect wird lokal erstellt, mes_option ruft das lokale mes_option auf: no Probs.Ich hab die DB kontrolliert, User wurde erstellt.
Nur kann ich mich nicht einloggen. Komischerweise kann ich mich auch nicht einloggen, wenn ich mit dem anderen DB-Prefix arbeite (wo der User garantiert richtig ist:-)Interessant ist, dass das System motzt, wenn man einen ungültigen User eingibt (also kommt das System doch auf eine DB), aber man kommt mit dem gültigen User nicht *ins" Redaktonsmenü, sondern zu einer weiteren Login Maske.
Ich glaube, ich muss in den Code steigen...
Es wäre zu schön gewesen, wenn das jetzt geklappt hätte:-)
Gruss
Patrick
_______________________________________________
Spip-de@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-de
Hoi Klaus,
>die Methode, die Du beschreibts verwende ich seit längerem ohne jedes Problem. Mit welcher Version von SPIP testest Du >das denn gerade?
<!-- 1.9.2 alpha -->
Ich hab die andere DB (spip) angeschnallt. Das System funktioniert an für sich, korrekt.
Nur einloggen kann ich mich so nicht.
Ich hab jetzt nochmals ein paar Test gemacht, man sieht dass ping von os7 und qu7 auf 80.74.143.185
Ich hab Dir einen Testuser erstellt: klaus/klausm
http://80.74.143.185/tools/spip/ecrire/ (einloggen geht)
Das ist sind VHOSTs (siehe unten) http://www.os7.ch/ Site geht (mit eigenen localen Daten)
http://www.os7.ch/spip/ecrire (Einloggen geht nicht)
(falls qu7 auf eine leere Apache-Site zeigt, ist der Nameserver noch nicht probagiert).
http://www.qu7.ch/ Site geht (verwenden SPIP aus anderem Verzeichnis)
http://www.qu7.ch/spip/ecrire (einloggen geht auch!!)
Vermutlich ist eine Variable falsch gesetzt:
Das war die letze Version
Wie gesagt, ich konnte den Upload machen, das inc_connect.php wurde im lokalen Pfad erstellt.
Gruss
Patrick
-------------------
mes_options.php (Installation)
$table_prefix = "spip";
$cookie_prefix = "spip";
$forcer_lang=true;
if ($_SERVER["SERVER_NAME"] == "www.os7.ch") {
# echo ($_SERVER["SERVER_NAME"]);
# echo("$f-{$r[1]}");
# $cookie_prefix = $table_prefix = $f = "/var/www/domains/artsky-n/http/spip_local/"; $table_x_prefix = "spip";
define('_SPIP_PATH', '/' . $table_x_prefix . '/:./:dist/:formulaires/:ecrire/');
define('_DIR_IMG', $f.'IMG/');
define('_DIR_DOC', _DIR_IMG);
define('_DIR_CACHE', $f.'CACHE/');
define('_DIR_SESSIONS', $f.'data/');
define('_DIR_TRANSFERT', $f.'upload');
define('_FILE_CONNECT_INS', $f.'inc_connect');
# echo (_FILE_CONNECT_INS);
$GLOBALS['dossier_squelettes'] = $f.'squelettes';
if (is_readable($f .= 'mes_options.php')) {
# echo("--$f"); require($f);
}
#echo($_SERVER['REQUEST_URI']);
#echo("{$_SERVER['REQUEST_URI']}-$r[1]-$f");
}
------------
Serverplatz:
/var/www/domains/artsky-n/http/
total 6
41697799 drwxr-xr-x 3 root root 1024 Oct 18 10:17 .
25510080 drwxr-xr-x 3 root root 1024 Oct 18 09:04 ..
67887109 -rw-r--r-- 1 root root 126 Oct 19 14:12 index.php
70049840 -rw-r--r-- 1 root root 46 Oct 18 09:16 index.txt
25510083 -rw-r--r-- 1 root root 20 Sep 21 16:40 phpinfo.php
41697807 lrwxr-xr-x 1 root root 20 Oct 18 09:05 spip -> /var/www/tools/spip/
41697806 drwxrwsr-x 4 775 www-data 1024 Oct 18 13:05 spip_local
41697806 drwxrwsr-x 4 775 www-data 1024 Oct 18 13:05 .
41697799 drwxr-xr-x 3 root root 1024 Oct 18 10:17 ..
67903537 drwxrwsr-x 19 root www-data 1024 Oct 19 15:43 CACHE
67903538 drwxrwsr-x 2 root www-data 1024 Oct 19 15:43 IMG
(Test, bewirkte aber nichts)
41697809 lrwxr-xr-x 1 root www-data 27 Oct 18 13:05 ecrire -> /var/www/
tools/spip/ecrire/
41697798 -rw-rw-rw- 1 www-data www-data 156 Oct 18 10:59 inc_connect.php
41697812 -rw-r--r-- 1 root www-data 15669 Oct 18 10:32 mes_fonctions.php
41697808 -rw-r--r-- 1 root www-data 117 Oct 18 11:40 mes_options.php
----------------
VHOST
<VirtualHost *>
ServerAdmin patrick.ogay@basel-inside.ch
ServerName www.artsky-n.ch
ServerAlias artsky-n.ch os7.ch www.os7.ch qu7.ch www.qu7.ch
DocumentRoot /var/www/domains/artsky-n/http
<Directory />
Options None
AllowOverride None
Order deny,allow
Deny from all
</Directory>
<Directory /var/www/domains/artsky-n/http/>
Options None Includes
AllowOverride None
Order allow,deny
Allow from all
Options Indexes FollowSymLinks
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
# RedirectMatch ^/$ /artsky-n/
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch -Includes
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>