I was implementing this module on a site where I wanted to have a search that searched nodes, pages, files and users all at the same time and ran accross an interesting issue.
When the search_by_page.module calls the sbp_query_modify to build the search query BOTH sbp_attach_sbp_query_modify() and sbp_nodes_sbp_query_modify() add a join to node_access in when required (when not using the user with uid = 1). This creates an sql error as {node_access} na appears twice in the FROM clause in the select.
In order to fix this I tried a couple of things - e.g. re-aliasing one of the node_access tables as na2 (like you had done for node in sbp_attach_sbp_query_modify() ) but this didn't work.
What worked in the end was moving the node_access check into a sub-query for both node and attachment searches.
I've attached a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 541958.patch | 4.58 KB | jhodgdon |
| node_access_issue.patch | 1.73 KB | alexpott |
Comments
Comment #1
jhodgdonThanks for reporting and patching! I'll look into this. I'm not sure sub-queries are supported in all versions of MySQL, so I might see if I can get it to work without the sub-queries somehow.
Comment #2
jhodgdonWhich module(s) are you using to control content access, or what special permissions do you have set?
The reason I am asking is that I am not getting this problem on my test site, even when searching with the anonymous user. But I have "access content" granted to anonymous, and no other special node access permissions, so that's probably the reason our sites are behaving differently.
Comment #3
alexpottJust using content_access... but any module that will cause _db_rewrite_sql to return a join to the node_access table should cause the issue if both sbp_nodes and sbp_attach are active.
I think just enabling the content_access module will be enough to create the issue. The important thing is to make it add a join to {node_access} twice in the $join variable in _search_by_page_do_search() function in search_by_page.module.
My MSQL version is 5.0.45
Comment #4
jhodgdonThanks. With Content Access module, I was able to set up a test case and reproduce your issue.
I also found a solution involving search and replace, which I think is preferable to using sub-queries (supposed to be faster). I put it into an API function, so that it can be reused in future sub-modules.
Can you try the attached patch and see if it works for you? Thanks in advance...
Comment #5
jhodgdonI have also committed this change to the development version (6.x-1.x-dev) of Search by Page, so if you wait until the next snapshot is generated, you can also download the (hopefully) fixed-up module later today from the Search by Page main project page.
Comment #6
alexpottUnfortunately the new patch in 6.x-1.x-dev doesn't work for me as it doesn't return any results when it should do...
If I disable either the attachments or the node module I get results but when both enabled and I search as a non-admin user I get no results.
Investigating further, the query the new patch generates when all search_by_page modules are enabled is:
I think the issue is with the inner joins on node_access... if I change these to left joins the queries return the same result as for my sub-select patch.
If I remove the part of the query for the nodes or the files I get a result so the issue is not with the node access records - also, as stated above if I disable either nodes or attachments I get a result - so almost certainly not a node_access issue.
Unfortunately changing the node_access join to a left join is not right as this would then give access to nodes the user is not supposed to have. As far as I know, the only way to solve this issue is with the badly-performing sub-selects or with a dreaded union select. The latter solution would require a re-write of do_search and therefore probably is not practical.
Any ideas?
Comment #7
jhodgdonIn my testing, that new version works correctly.
My testing set-up: I enabled Content Access, enabled per-item permissions, and created one page that was public and one that was private. I was able to replicate the behavior you had originally reported, when searching as the anonymous user. (First step in fixing a bug: replicate it!)
Then with the patch above (or the current dev snapshot), I got correct results: In the case where the search is on a word that is on a restricted page/attachment only, I get no results when searching as the anonymous user. If I search for a word that is in a public page, I get that page as a result.
So I'm a bit confused as to why it's working for me and not for you... maybe the reason it is working differently for you is that you have something more complex set up. Can you provide me with a description of your permission setup so I can try to replicate your problem (and hopefully resolve it) on my system? Thanks!
Comment #8
alexpottI'm confused too... :)
Maybe this is a mysql version issue - I'm on 5.0.45... stuck on RHEL5 unfortunately.
My permissions set up is a bit different... I have public and private node types... but the node_access records would be pretty similar.
However the following tests suggest this is not a node_access issue.
If I run this select I get 0 rows... (both nodes and attachments)
if I run this select... I get 1 row (attachment only)
And this returns 1 row too (attachments only)
Comment #9
jhodgdonI think the problem is that the Search by Page queries need some parentheses inserted.
Can you try this query and see if you get both nodes and attachments on your system (assuming the word 'week' appears in both)?
Comment #10
alexpottThe parentheses work great... never knew that they worked in joins...not too obvious from the MYSQL pages either... however having a quick look at MYSQL's doc we seem to have introduced a dependency on mysql versions...
Comment #11
jhodgdonExcellent, and thanks for finding that MySQL doc, which explains why things are working differently for you than for me.
I have just checked in a fix to the 6.1-dev branch that introduces parentheses into the Attach and Nodes joins (the others are simple one-table joins and don't need parens). Hopefully the new code will work equally well on my test site and your site. Let me know what you find out.
Comment #12
alexpottAll's working well... however through testing I did come across another issue... :) (will raise new issue once confirmed)
I can confirm that the module respects node_access permissions, the upload permission and cck field permissions.
Comment #13
jhodgdonI'll go ahead and mark this fixed then, since the fix is checked in to the 6.x-1.x-dev branch.
Comment #14
jhodgdonI decided there were enough urgent bug fixes to make an official release, so this is now fixed in version 6.x-1.2 of Search by Page.