[gelöst] Protokolleinträge: Formular-Fehler - unzulässige Auswahl (in exposed Filter)
Eingetragen von tetri999 (153)am 14.10.2015 - 12:50 Uhr in
Hallo,
ich habe (mehrere) Taxonomy-Seiten, die über einen Taxonomy-Term-PageView dargestellt werden.
D.h. über den contextualFilter taxTermID werden die entsprechenden Inhalte (als Teaser) aufgelistet.
Außerdem beinhaltet dieser View 4 exposed Filter (als DropdownBoxen mit useAjax: ON), mit denen der User die Teaser nach anderen zugeordeten Taxonomien filtern kann.
Diese Filter fange ich mit MY_MODUL_form_alter(&$form, &$form_state, $form_id) ab, um bei den Dropdown-select-options die Anzahl der jeweils dazugehörigen Einträge dazuzuschreiben
- und die, bei denen keiner gefunden wird, schmeiß ich mit unset($form[$curFilter]['#options'][$tid]); raus.
Das Problem:
Bei unserer Live-Site laufen ständig Protokollmeldungen auf der Art:
[domain]/[taxonomy/term/tid]?tax1_tid=xx&tax2_tid=yy&tax3_tid=zz&tax4_tid=abc&=Apply
Typ: Formular
Schwere: Fehler
Nachricht: Unzulässige Auswahl xx im Element tax1_tid ...Wie kommt das?
Es sieht so aus, als würden irgendwelche Robots auf diesen Seiten alle möglichen Kombinationen aus den select-options durchspielen - auch die gar nicht mehr vorhandenen.
Wie kann man das vermeiden - ich muß jeden Tag Dutzende von solchen Einträgen löschen!
mfG, Michael
- Anmelden oder Registrieren um Kommentare zu schreiben
Zitat:Es sieht so aus, als
am 14.10.2015 - 13:48 Uhr
Es sieht so aus, als würden irgendwelche Robots auf diesen Seiten alle möglichen Kombinationen aus den select-options durchspielen - auch die gar nicht mehr vorhandenen.
Genau - das sind meist Suchmaschinebots die die alten URLs aufrufen - diese aber nicht mehr vorhanden sind! Oder aber Bots von Scritkiddys die Sicherheitslücken suchen und die alles mögliche durchprobieren!
Wie kann man das vermeiden
Gar nicht! Wichtig dabei ist, dass die alten URLs einen 404 zurückgeben und dass Du einen canonical tag verwendest denn mit diesen zahlreichen select-options-Varianten erzeugt man praktisch unedlichen Dublicate-Content (mit den Pfaden die noch erreichbar sind).
Den Google-Bot kannst du aber über die Webmastertools anweisen bestimmte URLs nicht mehr aufzurufen - gegen alle anderen Bots kann man nichts machen!
- ich muß jeden Tag Dutzende von solchen Einträgen löschen!
Wieso musst Du die löschen? Drupal löscht die doch selbst nach einiger Zeit völlig automatisch!
Aber das sind doch gar keine URLs,
am 14.10.2015 - 14:22 Uhr
die Taxonomy-Seite hat einen canonical-tag "[domain]/[seitentitel]" und einen shortlink "[domain]/[taxonomy/term/tid]" - ohne irgendwelche URL-Parameter,
und die select-options aus den Dropdown-Filtern verweisen über AJAX ja immer auf die gleiche Seite - es gibt also gar keine "alten" URLs, die page-not-found liefern könnten.
Diese Einträge in dblog mit den Filterkombinationen kommen in unserem System als Seiten-URLs gar nicht vor - oder hab ich da was falsch verstanden?
Den auto-Cron hab ich abgeschaltet, ich mache das alle paar Tage selber - aber die Protokolleinträge werden dabei nicht gelöscht, kann man das irgendwo einstellen?
Michael
Zitat:und die select-options
am 14.10.2015 - 15:13 Uhr
und die select-options aus den Dropdown-Filtern verweisen über AJAX ja immer auf die gleiche Seite
User ohne aktiviertes Javascript (die kein Ajax verwenden können) können die Filter trotzdem nutzen indem sie "Apply" klicken und auf die Ergebnissseite weitergeleitet werden und ohne, dass die Ergebnisse mit Ajax auf der selben Seite aktuallsiert werden. Die Bots klicken also den "Apply" Button (und zwar mit jeder möglichen Kombination der verschiedenen Selectlisten/Radio-Buttons) und werden dann (ohne Ajax) auch auf die Ergebnisseite geleitet.
Das sieht dann so aus wie bei Dir im Anfangsthread!
www.domain.com/[taxonomy/term/tid]?tax1_tid=xx&tax2_tid=yy&tax3_tid=zz&tax4_tid=abc&=Apply
Wenn jetzt irgendwann einmal was an den Filtern geändert wird, funktionieren diese alten (schon einmal gespiderten) Pfade nicht mehr und beim nächsten Botbesuch erzeugt das dann den Fehler im Log (und die Scriptkiddys kommen auch noch dazu - die alles mögliche versuchen um eine Sicherheitslücke zu finden und alles denkbar/undenkbare an diesen Pfaden ausprobieren).
meine Lösung:
am 15.10.2015 - 13:23 Uhr
die Protokolleinträge waren ja keine 404er, sondern "Unzulässige Auswahl xx im Element tax1_tid ...".
Das kam wohl daher, daß ich die options, die keine Ergebnisse liefern würden - d.h. wo "LABEL (0)" stehen würde - mit unset($form[$curFilter]['#options'][$tid]); rausgeschmissen habe, so daß bei entsprechenden Kombinationen diese options gar nicht mehr da waren.
Jetzt habe ich sie stehen lassen und per jQuery mit jQuery("option:contains('(0)')" ).css( "display", "none" ); nur ausgeblendet - das scheint zu klappen, jedenfalls habe ich seitdem diese Protokolleinträge nicht mehr!
Oder gibt's gegen diese Methode Bedenken?
Michael