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.
An SA was just published for views:
https://www.drupal.org/node/2854980
The D6LTS vendors backported the patch to D6 which is attached
Comment | File | Size | Author |
---|---|---|---|
#23 | views-SA-CONTRIB-2017-022-23.patch | 8.4 KB | catch |
#20 | 2855030-20.patch | 8.72 KB | joelpittet |
#17 | views-db_rewrite_sql.2855030.patch | 4.51 KB | mr.j |
#16 | 2855030-16-name-ambiguous.patch | 908 bytes | joelpittet |
#6 | views-SA-CONTRIB-2017-022.patch | 4.31 KB | catch |
Comments
Comment #3
dsnopekCommitted to repo!
Comment #4
catchThanks for fixing up the patch and posting here!
Comment #5
dawehnerLooks good for me!
Comment #6
catchTwo bugs with this, one is trivial, one not so much:
1. db_rewrite_sql() has an $args parameter - dsnopek fixed my original patch which stopped passing $args to db_query(), but they should technically be passed to db_rewrite_sql() too. However I couldn't find a single implementation of db_rewrite_sql() that actually uses that param.
2. More importantly the original views queries are often written like SELECT td.* FROM term_data WHERE tid = %d. This is OK when not rewritten, but tac_lite adds a join, and you end up with 'ambiguous column tid in query' errors, needs to be td.tid = %d instead.
Comment #7
dsnopekAh, crap :-/
However, the patch in #6 doesn't appear to contain the 'tid' to 'td.tid' change, only the extra args from point 1
Comment #8
Jeremy CreditAttribution: Jeremy at Tag1 Consulting commentedThe fix is after the WHERE (you can't fix it in the SELECT as modules often check things like 'n' or 'td' etc).
Comment #9
dsnopekEr, actually, I'm not sure if changing 'tid' to 'td.tid' is right. And in re-reading #6 I can see that you're not actually suggesting that, that was just my misinterpretation. :-)
But here's why that isn't right: looking at some examples of
hook_db_rewrite_access()
, any that deal with taxonomy are doingif ($field == 'tid')
to see if the query deals with taxonomy. So, I think we need to actually fix the query not to use "SELECT td.*"Comment #10
dsnopekHm, and looking at the tac_lite code (I haven't actually tested), it shouldn't have this problem:
http://cgit.drupalcode.org/tac_lite/tree/tac_lite.module?h=6.x-1.x#n541
The
"$primary_table.tid"
should turn into "td.tid" and be not ambiguous, right?Comment #11
dsnopekOh, nevermind, please ignore my comments. I now see where the fix is. Thanks, @Jeremy!
Comment #12
dsnopekOk, I tested with tac_lite, was able to reproduce the problem, and tested the patch #6 which fixes the problem. Marking RTBC!
@catch: is there any more testing you want to do before committing this to the repo?
Comment #13
catch@dsnopek I tested with tac_lite and confirmed it fixed both the security issue (404 instead of showing term with empty listing) and didn't throw the warning. I had to head scratch a bit on exactly where the bug was as well.
I think it's ready to go, my testing wasn't 100% comprehensive but definitely caught one place and it's the same change on each query so I think it's OK.
Comment #14
dsnopekOk, great, thanks! I've committed the new patch to the repo
Comment #16
joelpittetNot sure if this is related but started seeing this in the logs and relates to tid mentions above being ambiguous.
Attached is a patch.
Comment #17
mr.j CreditAttribution: mr.j as a volunteer commentedYes this patch broke a few views for me, all of which use taxonomy filters or arguments. There are a few unprefixed "SELECT *" statements that fail when passed to db_rewrite_sql when using a node access module (in my case forum_access) as it can add more tables to the query and you get ambiguous column name errors. The previous patch on #16 doesn't catch all the potential errors. I made a github pull request with patches attached to this post here:
https://github.com/d6lts/views/pull/2/files
Comment #18
catchGood find, thanks for posting the patch.
There was another issue in the original patch, found by Fabianx. It shouldn't be a bug in practice, but if we're going to update the patch, better to do it once:
The docs for db_rewrite_sql() only mention using the full table names vs. the 'usual table aliases' (all one-letter). It's not a requirement but there's the potential for it being used as an implicit API if core's consistent.
Going to mark CNW for that, it's just a change from td to t everywhere for the alias.
Comment #19
dsnopekComment #20
joelpittetAddressing 'td' being 't' from @catch.
Comment #21
dsnopekThe code changes in this look great! I haven't yet had chance to actually test this, though, which is the big thing.
Comment #22
catchI also haven't tested this yet, but visually it looks great.
Comment #23
catch#20 is an interdiff against #6.
Here's a combined patch that will apply against views-6.x-3.2
Tested fine for me, so moving to RTBC.
Comment #24
dsnopekRTBC +1
It took me way too long to reproduce the bug, but I was finally able to using forum_access and a View that had and exposed filter for TID using the autocomplete. And the patch fixed it!
Thanks, Everyone!
Comment #25
dsnopekCommitted!