Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When an anonymous user without the "access profiles" permission tries to view search/user an error message is shown instead of the access denied message.
Fatal error: Cannot unset string offsets in includes/form.inc on line 301
Comment | File | Size | Author |
---|---|---|---|
#19 | search_23.patch | 1.32 KB | Steven |
#18 | search_22.patch | 1.2 KB | chx |
#17 | search_21.patch | 1.37 KB | Steven |
#13 | search_20.patch | 1.24 KB | chx |
#11 | search_19.patch | 1.16 KB | chx |
Comments
Comment #1
Jose Reyero CreditAttribution: Jose Reyero commentedConfirmed the bug.
it happens also for regular users with access profile permission, when the search type argument is some other word than 'node', 'user'
I.e. for this path: /search/one/two
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commentedI think the problem was the menu system calling drupal_get_form('menu_view'), but menu_view doesn't return a form structure.
Here's the patch which also adds some more control on the parameters that are passed to menu_view.
Comment #3
drummCommitted to HEAD.
Comment #4
(not verified) CreditAttribution: commentedComment #5
chx CreditAttribution: chx commentedThis caused http://drupal.org/node/108587 , I now try to roll this one back and re fix this issue.
Comment #6
chx CreditAttribution: chx commentedSo the problem was that search/user did not work after this patch, because submitting to search/user meant that the callback for 'search' was called and that had a wired in 'node' callback argument.
Given that search module redirects from the path
search
tosearch/node
anyways because$type
is empty, the fix is quite simple: we just need to remove the callback argument.Comment #7
ChrisKennedy CreditAttribution: ChrisKennedy commentedThe patch does restore user searching functionality, but doesn't fix the original issue of displaying an access denied message when an anonymous user without "access profiles" permission manually visits search/user. With the patch a search box and button are displayed that don't return any results (for users without "access profiles" permission).
Comment #8
chx CreditAttribution: chx commentedI can not reproduce what ChrisKennedy describes. Have you rebuilt your menu?
Comment #9
chx CreditAttribution: chx commentedA screenshot.
Comment #10
ChrisKennedy CreditAttribution: ChrisKennedy commentedI get the access denied error if the user doesn't have "search content" access, but if they have "search content" but not "view user profiles" I just get the non-working search box for search/user. You get "access denied" in the second case too?
This is after deleting cache, cache_menu and cache_page.
Comment #11
chx CreditAttribution: chx commentedAh yes. Let's see this one. Note that user_search protects every op with appropriate permission check.
Comment #12
ChrisKennedy CreditAttribution: ChrisKennedy commentedOk this version works correctly.
Two more suggestions: add a comment and tweak the regex to allow module names with numbers.
Comment #13
chx CreditAttribution: chx commentedAccording to Chris the version already worked correctly, I just added comment and numbers.
Comment #14
ChrisKennedy CreditAttribution: ChrisKennedy commentedYup, looks good.
Comment #15
Steven CreditAttribution: Steven commentedWhy on earth are you using a regular expression? Just check if the hook returns an empty string or not.
Comment #16
Steven CreditAttribution: Steven commentedIn fact, I think this is a completely wrong approach. In search_menu():
In other words, if you go to "search/user", a dynamic menu item "search/user" is created (as $keys == '') which should take precedence over "search".
Comment #17
Steven CreditAttribution: Steven commentedIn fact, so search_menu() already checks if the search provider advertises itself. So, the solution is relatively simple... we define an explicit 403 menu item for the case when 1) the search type is supported but 2) the permissions are not set.
The result is that search/user will properly return a 403, and will not require a useless invocation of search_view('user') like in the earlier patch. If you use a non-existant search type, it's as if it wasn't there (e.g. search/foobar == search) and you get the regular node search. This is in line with other drupal behaviour (e.g. admin/foobar == admin).
Comment #18
chx CreditAttribution: chx commentedI was hovering around this solution for a while but could not get it right. In your wisdom we are humbled.
But still, this can be written in less code.
Comment #19
Steven CreditAttribution: Steven commentedLess code is good, but chx's patch defines a 403 menu item for every module, even those that don't implement search (like color or watchdog). This is bad too, so I re-added the hook check.
And of course, module_list() + module_hook() = module_implements(). Even less code!
Comment #20
Steven CreditAttribution: Steven commentedCommitted with Dries' okay.
Comment #21
dldege CreditAttribution: dldege commentedThere is still a bug in search in DRUPAL-5-0 that search forms all submit to search/node. This patch seems related but didn't fix that problem.
See http://drupal.org/node/108925
Thx.
Comment #22
(not verified) CreditAttribution: commented