Vorgestern war mir Gelächter sicher. Ich entwickle gerade mit mehreren Kollegen zusammen ein Informationsportal mit dem agentureigenen CMS. Als besonderes Feature habe ich einen Inlineeditor entwickelt, den man von anderen Content Management Systemem wie z.B. Typo3 kennt. Mit ihm kann man direkt auf der Webseite Inhalte und Downloads anlegen, bearbeiten und auch wieder löschen.
Zusätzlich ist für das Portal eine Suchmaschine angebunden, die über einen Crawler indexiert. Da das Portal ein geschlossener Bereich ist, muss man sich als Besucher (und natürlich auch der Crawler) zunächst mit einem gültigen Benutzer anmelden.
Jetzt der Schock: Nach dem 1. Crawlerdurchlauf waren alle Inhalte weg! Wie passiert sowas? Mein Kollege hat zum Indexieren das Benutzerkonto des Webmasters oder Administrators verwendet. Sobald man sich mit einem Administrationsbenutzer anmeldet und Rechte an der aktuellen Seite hat, steht dem Benutzer als Option der Inlineeditor zur Verfügung.
Mist! Der Admin hat natürlich das Recht an jeder Seite. Und weil der fleissige Crawler sich nichts dabei denkt, klickt er schön jeden Link an:
- Schalte Bearbeitungsmodus an
- Bearbeite alle Seiten (Da passiert natürlich nix)
- Lösche alle Seiten und Downloads rekursiv (Ups)
- Beende den Bearbeitungsmodus
- Beende den Crawlvorgang
- Stelle den erzeugten Index der Suche zur Verfügung
Gabs denn keine Sicherungen, um sowas zu vermeiden? Doch, doch…
- Man muss im Bearbeitungsmodus sein, um Löschen zu können
- Den Bearbeitunsmodus kann man nur starten, wenn man Autor oder Admin ist
- Man muss Schreibrechte an der Seite/Download haben
- Javascript-Sind-Sie-Sicher-Abfrage vorm Löschen mit Ja/Nein Option
Gut, auf den 1. Blick sticht natürlich ins Auge, dass nur eine Javascriptabfrage bei onclick mit return true/false implementiert ist. Meine lieben Kollegen waren der Auffassung, das eine PHP-Abfrage das Löschen-Fiasko hätte verhindern können. Aber: falsch gedacht - Denn die PHP Abfrage, die ja wieder nur eine HTML Abfrage generiert, hätte der Crawler ja auch angeklickt.
Oder vielleicht doch? Aber ich bin mir sicher, die wenigsten hätten die folgende Prüfung eingebaut. Es rechnet ja niemand damit, das ein Crawler eine komplette Seite fressen kann…
Die Lösung wäre in der Tat eine PHP Abfrage mit HTML Output gewesen: Der Benutzer wird vor dem Löschen also via HTML Text und zwei Links (Ja/Nein) gefragt, ob die Seite/Datei gelöscht werden soll. Der erste Link (Die Reihenfolge ist wichtig !) ist NEIN oder Abbrechen. Bei Klick wird aber nicht nur zur Ausgangsseite zurückgesprungen, sondern ein Flag gesetzt, das NEIN geklickt wurde.
Bei Klick auf JA muss überprüft werden, ob vorher bereits NEIN geklickt wurde. Wenn ja, dann Abbruch - andern falls löschen. Das Ist-Nein-Geklickt-Flag muss natürlich beim erneuten Anzeigen des Abfragedialogs wieder auf NULL gesetzt/initialisiert werden, damit ein echter Benutzer auch die Möglichkeit hat, es sich noch einmal zu überlegen…
So, jetzt meine Frage: Wer im Himmel hätte so eine Abfrage implementiert? Wir nicht :-( Auf jeden Fall hat der Crawler jetzt einen eigenen Account mit Besucherrechten - Das ist immer noch das sicherste Komdom für den Crawler des Todes!
