I have a problem with Views that I'm hoping someone can explain to me. I find this mystifying, and it also happens to be hurting my site significantly. I'm hoping it's just something I don't understand about Views:
- I have a View that displays a list of nodes filtered by <(term) Taxonomy term: Vocabulary (= Library)>.
- It also has a single Contextual Filter for <(term) Taxonomy term: Name>. When the contextual filter value is NOT in the URL, it's set to "Display all results for the specified field".
If any value is entered after the url http://oursite.com/library that is NOT a valid taxonomy term, I get a WSOD. This is throwing hundreds of errors into our server errors logs and my host is reporting this is severely compromising the site's performance, sometimes to the point of locking the site up.
Earlier this year, I had another View that was similar -- it had a contextual filter and any random string of data placed after the base URL for the View would not only cause an error, it often produced such as crash/hang, it would shut down my whole site!!! Because our site's been around for over a decade, there (as I've come to learn by studying the error and access logs) are literally hundreds of URLs out there like this (in search engine indexes, hackers' databases, or whatever -- I don't know). So, our site was regularly getting requests for the URL with bad query strings where the View wanted a valid contextual filter value; and our site would freeze up. The only solution was to disable the View or remove all Contextual Filters.
How can views be set up to work like this? Isn't this like having a house with no locks, and relying on the conditions that no one will try to open the door and walk in and take stuff? My understanding is your typical public server is set to not respond to, say, requests on a port that is not authorized; so rather than letting a hacker into it, it just acts like the port doesn't exist. Why isn't Views set up that way? Why, if it gets a bad request, doesn't it just ignore it, rather than getting stuck in some kind of giant loop analogous to a Denial of Service attack? I'm not being critical or argumentative -- I'm really just confused that Views could be vulnerable like this just from including simple contextual filter.
I'm hoping there's just some setting I'm not understanding that is to blame for this. This is an extremely serious matter for our site. Can someone please give me any insight or guidance on this matter?
In case it's helpful, heres some of the recent server error logs as an example of this issue
Error Log
18
Unsupported operand types sites/all/modules/views/includes/handlers.inc:1032
last error was 21 minutes ago
CALL STACK
# Function Location
1 views_many_to_one_helper->add_filter() /sites/all/modules/views/handlers/views_handler_argument_string.inc:186
2 views_many_to_one_helper::add_filter() /sites/all/modules/views/includes/handlers.inc:1032
3 view->_build_arguments() /sites/all/modules/views/includes/view.inc:992
4 views_handler_argument_string->query() /sites/all/modules/views/includes/view.inc:830
5 views_plugin_display_page->execute() /sites/all/modules/views/includes/view.inc:1337
6 view->build() /sites/all/modules/views/plugins/views_plugin_display_page.inc:216
7 views_page(library_index, page_summary, cats) null:null
8 view->execute_display(page_summary, Array ([0] => cats)) /sites/all/modules/views/views.module:526
9 menu_execute_active_handler() /index.php:21
10 call_user_func_array(views_page, Array ([0] => library_index,[1] => page_summary,[2] => cats))
Comments
Comment #1
mustanggb commented