current environment
Drupal 6.13
Hi,
I'm using apache solr in 2 environments
Apache Solr Framework 6.x-1.0-rc2
Apache Tomcat - 5.5.27
Solr Nightly Build - solr-2009-05-27.tgz
Apache Solr Framework - 6.x-1.0-beta10
Apache Tomcat - 5.5.28
Solr Nightly Build - solr-2009-08-25.tgz
Now after upgrading Apachesolr module, Tomcat and Solr the links on the apachesolr blocks are generating incorrect links for fields which have an ampersand '&' in them.
For example when the Architect Name contains
Brooke Michl-Smith, Senior Architectural Designer, Karlsberger, Architects, Columbus, Ohio Martin & Martin, Engineers, Lakewood, CO
it generates the following 2 links
[root@bfc33 tmp]# cat 1.txt
working - http://www.old.com/search/apachesolr_search/lipski?filters=sm_cck_field_...
broken - http://www.new.com/search/apachesolr_search/lipski?filters=sm_cck_field_...
it generates %2526amp instead of %26amp
thx.
yashesh bhatia
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | 562214-D6-1.patch | 1006 bytes | jpmckinney |
| #35 | 562214-D6-2.patch | 1.08 KB | jpmckinney |
| #35 | 562214-D7.patch | 1.09 KB | jpmckinney |
| #32 | apachesolr-5-2.patch | 1.07 KB | wmostrey |
| #32 | apachesolr-6-1.patch | 1.1 KB | wmostrey |
Comments
Comment #1
yasheshb commentedi did a diff between the b10 and rc2 versions of apachesolr.index.inc
and noticed the htmlspecialchars in b10 is using double_encode=FALSE, but that is not the case in rc2. would this be causing the double encoding attempt for & to & ?
php version is 5.2.9
thx.
yashesh bhatia
Comment #2
yasheshb commentedhi, i changed
to
deleted the index and rebuilt it but am getting the same problem. back to debugging.
thx
yashesh bhatia
Comment #3
pwolanin commentedI think & has been an issue in all versions -I'd be surprised if you ever saw it working.
Comment #4
yasheshb commentedu can try it at
http://publicart.callforentry.org/
type 'lipski' in the search box
it gives u - http://publicart.callforentry.org/search/apachesolr_search/lipski
click on the 3rd link in the 3rd block.
"Brooke Michl-Smith, Senior Architectural Designer, Karlsberger, Architects, Columbus, Ohio Martin & Martin, Engineers, Lakewood, CO (1)"
and it goes to
http://publicart.callforentry.org/search/apachesolr_search/lipski?filter...
works fine for 6.x-1.0-beta10
Comment #5
yasheshb commenteddigging a bit more into the file apachesolr.module and specifically the functions apachesolr_facet_block and apachesolr_l it seems the problem is in the apachesolr_l. here's the breakpoints output from the function
The above debugging statements are the parameters and the return value from the function apachesolr_l in apachesolr.module
i'll dig more deeper, it's not solved yet but wanted to share the debugging information.
yashesh bhatia
Comment #6
yasheshb commentedsorry i forgot to mention the drupal versions clearly.
Working code - Drupal 6.10, apachesolr 6.x-1.0-beta10
Broken code - Drupal 6.13, apachesolr 6.x-1.0-rc2
i'll debug the common.inc for the function url() for drupal 6.10 and 6.13
yashesh
Comment #7
yasheshb commentedsome more debugging. it's breaking down in includes/common.inc in function url().
at the place
now need to find out why the two $options are different or is it a bug with the function drupal_query_string_encode
Comment #8
yasheshb commentedsome more debugging
it seems the way the links are generated in the function apachesolr_facet_block is causing the problem
the way the links are generated is different for the theme functions apachesolr_facet_link and apachesolr_facet_item
Comment #9
robertdouglass commentedThis all comes down to the following line:
The check_plain($text) does it. To fix I'm sending $options['html'] = TRUE; into the apachesolr_l call.
Comment #10
robertdouglass commentedComment #11
yasheshb commentedhi. i applied the patch. but it's not fixing the url yet. here's the debugging information in the function apachesolr_l
here's the theme function theme_apachesolr_facet_link after the patch was applied
thx
yashesh bhatia
Comment #12
jpmckinney commentedComment #13
drummSetting correct status
Comment #14
pwolanin commentedNeeds confirmation that this is still a bug when using the latest code.
Comment #15
finn lewisI think this is still an issue with the latest 6.x-2.x-dev code, but I haven't tried with 6.x-1.x-dev.
I updated to the 6.x-2.x-dev 2010-Jul-26 and still get ampersands displayed as
&in the current search and filter blocks.Forcing $options['html'] = TRUE; does seem to fix it, but I'm not sure exactly where this is best done.
In the apachesolr.module there's the theme_apachesolr_unclick_link funtion.
This seems to unset the $options['html'] value - presumably because the apachesolr_l function adds $options['html'] = FALSE;
So adding $options['html'] = TRUE to every call to theme_apachesolr_unclick_link would simply prevent it from running the link text through check_plain().
But in Robert's solution to the initial problem above in #9 we do pass $options['html'] = TRUE; to apachesolr_l().. contrary to what is suggested in
theme_apachesolr_unclick_link().
So I'm unclear as to which way is best.
I think the two theme functions theme_apachesolr_unclick_link() and theme_apachesolr_facet_link() should probably be consistent in how they deal with $options['html'] = TRUE;
So should they:
1) Force $options['html'] = TRUE; in both functions and pass this to apachesolr_l()
2) Add the check for $options['html'] to both functions, and only check_plain() if html is FALSE or not set (as in theme_apachesolr_unclick_link).
Currently I have simply passed $options['html'] = TRUE; to all calls to theme_apachesolr_unclick_link and it seems to work for me.
Any suggestions or am I missing something obvious?
Comment #16
pwolanin commentedforcing html to true in all cases may subject your site to a serious security vulnerability.
Comment #17
finn lewisIn Robert's patch in #9 above he adds $options['html'] = TRUE; for everything passing through theme_apachesolr_facet_link() - does this introduce a security vulnerability?
Comment #18
finn lewisI am still having this issue with the double encoding of ampersands using 6.x-2.0-beta3 and am looking for a solution that doesn't force $options['html'] = TRUE to prevent check_plain() on the output, as I would like to avoid the potential security vulnerabilities mentioned above.
I am not 100% sure how many times check_plain() or htmlspecialchars() are being called on the values in question, but it must be more than once.
Anyway, my current solution is as follows:
In the apachesolr.module - the function apachesolr_l() calls check_plain() when returning the link. I add $text = html_entity_decode($text); just before this to decode any encoded ampersands (or other html entities... )
Then, in theme_apachesolr_unclick_link() I added a similar line:
Now all my ampersands are ampersands again, which is nice.
I am not sure if this is the right way to go and would welcome any pointers or suggestions.
Patch attached (patch created against 6.x-2.0-beta3).
Comment #19
wmostrey commentedThe problem still exists in the current 6.x-2.x-dev release. I tried the patch in #18 but that didn't fix the issue.
For example: "walk&talk" becomes "walk%2526talk" in the browser's address bar and "walk%26talk" in the search bar.
Comment #20
robertdouglass commentedComment #21
pwolanin commented@wim - so it's going from the path to the search box that's the only problem?
NO ONE HAS GIVEN ME STEPS TO REPRODUCE! Marking postponed until someone posts steps to reproduce.
Comment #22
wmostrey commentedI find it easy to reproduce: In the search field I enter "walk&talk" and click the search button. I get redirected to the search results, in which the search field now contains "walk%26talk", and no results are found for this search term.
Comment #23
pwolanin commentedOk, so that test seems to work correctly in 6.x-1.x, so let's compare the code.
Comment #24
wmostrey commented(Can we put the status back to active to attract more eyes on this issue?)
Comment #25
pwolanin commentedComment #26
wmostrey commentedNote that in the same way a "+" also changes into "%2B". I think these are the only characters that cause this kind of behavior.
Comment #27
wmostrey commentedPlease note that all solutions so far focussed on apachesolr_l and theme_apachesolr_unclick_link. But this doesn't change the behavior when entering "this&that" in the search field and performing the search.
Comment #28
wmostrey commentedIt would be advisable for everyone partaking in this issue to also state if they're using Apache or Nginx, and if they're using Tomcat or not (and if so, what the server.xml looks like). It could very well be that the problem is not just apachesolr, or at least not for everyone.
Comment #29
wmostrey commentedPlease ignore the problems I reported since #19. The behavior I was experiencing were specific for Nginx, I don't experience them on Apache. Fixing these issues should go in another issue (which I will create and post a patch for later this week).
The one remaining problem in this issue is that the links in a filter block display
&as&. To reproduce:I tested the patch in #18 which fixes the problem completely.
Comment #30
johannesdr commentedtested the patch and it works for me. Problem solved.
Comment #31
pwolanin commentedWe want to be use the same solution in 6.x-1.x and 6.x-2.x. Please compare the code and tell me what's different and make a patch to fix it in that way.
Is that what the patch in #18 does? The poster doesn't say.
Comment #32
wmostrey commentedThat is exactly what the patch in #18 does: It adds the necessary decoding so that an ampersand in $text shows up as
&and not as&.Here are the patches for 5.x-2.x, 6.x-1.x and 6.x-2.x.
Comment #33
soyarma commentedWould I be correct in assuming that pw's comment in #31 is moot then, since this issue appears in 6-1.x as well as 6-2.x?
If that is the case, I'm willing to endorse the addition of this to the 2.x branch
Comment #34
wmostrey commentedExactly, and that's why the patches in #32 are for. Thanks!
Comment #35
jpmckinney commentedThis has gone on long enough. Fixed in 5.2 (forgot to create patch), 6.1, 6.2 and 7.
Comment #36
pwolanin commentedSorry I didn't review in more detail before, but seems like we ought to decode more selectively, e.g. using htmlspecialchars_decode()?
Comment #37
jpmckinney commentedWon't check_plain re-encode the decoded entities? I don't want to see future issues about double encoded open-angle bracket (<).
Comment #38
pwolanin commentedYes, check_plain will re-encode them - that's the point. We want the text to be safe, but not double encoded.
Comment #39
jpmckinney commentedI defer to you. My understanding is that check_plain(html_entity_decode($text)) is safe.
Comment #40
pwolanin commentedyes, it should be safe, just wondering if we are overly decoding. Anyhow, let's leave it for now.