Problem/Motivation
Referer, if present, MUST NOT be blank, according to RFC 2616, and so whatever reason this was put in for, it needs to be rewritten and/or removed. It interferes with Bad Behavior's check of the Referer value and offers absolutely no benefit to Drupal or anyone else, while inducing RFC-noncompliant behavior.
Proposed resolution
Remove code in drupal_environment_initialize()
Remaining tasks
Commit it
User interface changes
None
API changes
None
Original report by @jlea9378
Bad Behavior is blocking me (and lots of other people) from accessing my Drupal 7 site. I never had a problem when using Drupal 6. The reason given in the log is that the referrer is blank. I tried disabling all of my addons in firefox and also tried using Internet Explorer instead, but no matter what I get blocked. I must have deleted my cookie on accident because now I can't even get in using https instead of http. So I'm totally blocked now. I tried using a different computer also, and I get blocked there as well. It seems like Bad Behavior on Drupal 7 is extra-sensitive or something...?
Using the latest version of Bad Behavior and library as of 10/26/12: version 2.2.11
Drupal 7.16
My support key is: ac10-0019-6992-0ee5
Comment | File | Size | Author |
---|---|---|---|
#100 | 1824360-73-bootstrap-http-referer-rfc2616-d7.patch | 2.33 KB | dcam |
#91 | 1824360-91-bootstrap-http-referer-rfc2616-d8.patch | 1.75 KB | Mixologic |
#73 | 1824360-73-bootstrap-http-referer-rfc2616-d7.patch | 2.33 KB | Anonymous (not verified) |
#70 | 1824360-70-http-referer-bootstrap-simpletest.patch | 1.27 KB | Anonymous (not verified) |
#69 | 1824360-69-bootstrap-inc-http-referer.patch | 595 bytes | Anonymous (not verified) |
Comments
Comment #1
gregarios CreditAttribution: gregarios commentedAre you using a proxy server that isn't allowing referrer reports to get to your Drupal installation? It sounds like it may be a server-configuration problem to me, since most browsers and personal computers allow and send referrer reports by default.
Comment #2
jlea9378 CreditAttribution: jlea9378 commentedNope, no proxy server. Our web server is running behind a DMZ. When trying to browse to the site from my home computer or from my office computer I get that error. My office is on the other side of the DMZ on the protected side of the network. We don't use a proxy server at the office, and I don't use one at home either. At home I just have a typical home cable modem and router.
The link to the site is: http://web.clatsopcc.edu:8000/
That's the test copy of our site. I had it installed on the production site (which is on port 80 and hostname is www) but someone notified me that they couldn't access the site, so I turned it off.
Comment #3
gregarios CreditAttribution: gregarios commentedI am unable to get to the website you listed because of Bad Behavior kicking in as well. It sounds like you m,ay have an unique issue, as we have not received an influx of other users having this problem.
Are you sure the "Clatsop Community College" network doesn't have some kind of firewall preventing Bad Behavior from working? You should turn off any firewall temporarily for the purpose of troubleshooting your issue if possible.
Your best bet would be to disable all modules on the site except Bad Behavior and see if the issue still exists. There may be some incompatibility going on with your particular setup.
Any details would also be helpful in this:
Web Server Software:
Web Host:
Firewall settings if any:
Comment #4
jlea9378 CreditAttribution: jlea9378 commentedWe host the server ourselves. It's on a Red Hat EL5 server in our vmware virtual server environment:
mysql 5.0.95-log
php 5.3.5
Apache/2.2.3 (Red Hat)
Even browsing to the site on the Linux webserver itself causes Bad Behavior to kick in, so it doesn't appear to be a firewall problem.
I just tried disabling all modules, uninstalling the Bad Behavior module and reinstalling it, but that didn't help. I still get blocked, even when browsing to the site from the GUI on the webserver itself.
Comment #5
gregarios CreditAttribution: gregarios commentedIt appears your site is working with the Bad Behavior module installed at this time. Would you mind reporting back to let us know what the problem was? It may help others in the future.
Comment #6
jlea9378 CreditAttribution: jlea9378 commentedNo, it's not working. I am still getting blocked every time from different computers.
Comment #7
gregarios CreditAttribution: gregarios commentedIt is no longer blocking me. It was before.
This isn't really the issue forum to consult if you think it is the Bad Behavior logic, however, since it is a non-Drupal third-party script that handles all the blocking itself. You should go here to submit your problem and see if there is anything they can find out:
http://bad-behavior.ioerror.us/support/troubleshooting/
As a matter of fact, if you are getting the Bad Behavior "blocked" message, then the Drupal module is, in fact, working correctly. (Even if the Bad Behavior library isn't)
Comment #8
jlea9378 CreditAttribution: jlea9378 commentedI contacted the Bad Behavior team and got a response. Here is what Michael Hampton said:
As an experiment, on the webserver GUI, I logged in to the site via Firefox and completely disabled the caching in Drupal on the test website (I had to rename the bad-behavior library to even get back in because it kept blocking me). I cleared the cache to make sure it was clean, logged out, changed the name of the library back to the correct name, and closed the browser. Then I launched the browser again and navigated back to the test site. Once again I was blocked. If it helps, the key is: ac10-0a11-6992-0ee5. Note that all other Drupal modules, aside from Drupal Core modules and the Bad Behavior module, are disabled. So it doesn’t seem to be a Drupal caching problem. Especially since I can’t get back into the site unless I rename the Bad Behavior library folder…
Explicitly putting the address in of https://web.clatsopcc.edu:8443/user/login doesn’t even allow me to get back in unless the Bad Behavior library is missing.
Comment #9
gregarios CreditAttribution: gregarios commentedSince you disabled Drupal's internal caches, and still had to rename the library to get back in... that suggests that you may have some kind of Apache or PHP caching that is causing this behavior. You may want to look at this and add the Bad Behavior library to "exempted" files to those caches if possible. (Could be settings in caches such as MemCache, APC, mod_cache, etc...)
Also completely disable any browser caching that may interfere. Make sure, when running Bad Behavior, that you do not ever use "external" or "aggressive" caching in the Drupal settings.
Comment #10
jlea9378 CreditAttribution: jlea9378 commentedYes we use APC in our LAMP stack. I see there is a way to exclude certain files from APC using this php.ini directive: apc.filters
I'm not sure what I should put for the regex though. What files should I be excluding? Everything in the bad-behavior module and library folders?
Comment #11
gregarios CreditAttribution: gregarios commentedIf you're using APC then a simple restart of Apache may be all that is needed to make sure the newest PHP documents are all brought into cache whenever new modules or libraries are added/modified. Also, make sure you have the following settings stated in the APC section of your php.ini file:
Comment #12
jlea9378 CreditAttribution: jlea9378 commentedDone. I also added bad-behavior and badbehavior to the filter list and verified that they are excluded via the web interface to APC. However none of those changes have helped. Bad Behavior is still blocking me relentlessly, even after a fresh reboot of Apache and PHP-FPM.
Comment #13
carsonwI've been having the same issue as jlea9378, and so I'm disabling this module until I can figure out what the heck is going on.
Comment #14
Kutakizukari CreditAttribution: Kutakizukari commentedI'm having the same issue with http://vegan5technique.com. I'm logged in as admin with firefox and can view fine but if I use Google Chrome or Internet Exploroer I get:
and can't view the site.
I also have no proxy's running and did not have this problem with the Drupal 6 version.
Comment #15
Kutakizukari CreditAttribution: Kutakizukari commentedI did not have caching enabled when I installed BB and it still blocks Internet Explorer and Chrome but not Fire Fox though I installed when logged into the admin and have not logged out of fear of not getting back in.
Comment #16
jlea9378 CreditAttribution: jlea9378 commentedYah I didn't have any problems until I upgraded to Drupal 7 -- it worked great under Drupal 6. If you get locked out, just rename the Bad Behavior library directory to something else, like bad-behavior-foo. I've been locked out several times now...
Comment #17
Kutakizukari CreditAttribution: Kutakizukari commented@carsonw: I also have disabled the module because it was blocking everyone who came to my site.
Comment #18
gregarios CreditAttribution: gregarios commentedIt would appear the Bad Behavior Drupal module is working correctly. If you are having specific blocking issues, you will need to contact the Library maintainer at: http://bad-behavior.ioerror.us/support/troubleshooting/
If it is found that there is a problem with the Drupal module, I will look into this further.
Comment #19
error CreditAttribution: error commentedI cannot reproduce this issue on a freshly installed Drupal 7 test site. So it doesn't seem to be an issue with the core Bad Behavior code. I'll keep poking at it, but I don't really expect to get too far. It might help if those of you running into this issue can provide a LOT of detail about your server environment, other Drupal modules in use, etc.
Comment #20
Kutakizukari CreditAttribution: Kutakizukari commented@error when I get a change I'll install another live site and go through each module to see if one keeps it from working like it is on my currect site.
One module right off the bat that might keep it from running correctly is the PHPIDS module: http://drupal.org/project/phpids.
Using the 7.x-1.x-dev version on a live site, when I get a change I'll check that one out.
Comment #21
Kutakizukari CreditAttribution: Kutakizukari commentedJust tried disabling the PHPIDS module: http://drupal.org/project/phpids and it still blocks me from chrome and IE but not FireFox since I'm login as admin.
@jlea9378 Would comparing modules help narrow down the culprit?
Comment #22
Kutakizukari CreditAttribution: Kutakizukari commentedHere is a screenshot of the modules I have installed and available. Hope this helps.
Comment #23
jlea9378 CreditAttribution: jlea9378 commentedI get blocked even when I have all non-core modules disabled, aside from Bad Behavior.
Comment #24
rahim123 CreditAttribution: rahim123 commentedHi, I have this same issue. Bad Behavior works great on Drupal 6 on the same server.
URI /favicon.ico
PROTOCOL HTTP/1.0
USER AGENT Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
HEADERS GET /favicon.ico HTTP/1.0 Host: libretechtips.com X-Forwarded-Host: libretechtips.com X-Forwarded-Server: libretechtips.com X-Forwarded-For: 190.152.33.194 Forwarded-Request-Uri: /favicon.ico Http-X-Forwarded-Proto: http Https: off X-Forwarded-Proto: http X-Forwarded-Ssl: off Connection: close Accept: */* User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Referer:
REQUEST ENTITY
DENIED REASON Header 'Referer' present but blank
EXPLANATION An invalid request was received from your browser. This may be caused by a malfunctioning proxy server or browser privacy software.
RESPONSE 400
Comment #25
Kutakizukari CreditAttribution: Kutakizukari commented@jlea9378 Confirmed, just installed @ http://8bitplatyp.us/drupal/, after that:
$ drush dl badbehavior
$ drush en badbehavior
Went to visit with Chrome and I get:
Error 400
We're sorry, but we could not fulfill your request for /drupal/ on this server.
An invalid request was received from your browser. This may be caused by a malfunctioning proxy server or browser privacy software.
Your technical support key is: 46c1-0a58-6992-0ee5
You can use this key to fix this problem yourself.
If you are unable to fix the problem yourself, please contact email and be sure to provide the technical support key shown above.
Comment #26
error CreditAttribution: error commentedI just checked http://8bitplatyp.us/drupal/ and Bad Behavior seems to be working fine. Please let us all know what the secret to fixing this was!
Comment #27
error CreditAttribution: error commentedI'm pretty well convinced at this point that there's some other code or configuration issue going on. I've now built two completely different test machines and been unable to reproduce the issue, with only the core extensions/themes and Bad Behavior installed.
I'd still like to track this down, obviously, so if you're having this issue, please send the following information:
drush pm-list
Hopefully we can get to the bottom of this soon.
Comment #28
gregarios CreditAttribution: gregarios commentedThat's interesting... when I visit http://8bitplatyp.us/drupal/ in Safari I get this:
But I get to a Drupal login if I visit in Firefox on the same machine.
I'm running OSX 10.8.2, Safari Version 6.0.2 (8536.26.17), and Firefox 17.0.1.
Comment #29
Kutakizukari CreditAttribution: Kutakizukari commented@gregarios Using Firefox 16.0.2 & 17.0.1 I get the login page with no content which has not been created yet but Drupal usaly has some things to do for the start page.
Using Chrome Version 23.0.1271.95 m & Internet Explorer 9 64-bit I get the error.
@error Going to start gathering the information for you.
Comment #30
jlea9378 CreditAttribution: jlea9378 commentedmysql 5.0.95-log
php 5.3.5
APC: 3.1.6
Apache/2.2.3 (Red Hat)
Server API: FPM/FastCGI
Built from mod_fastcgi-2.4.6 source
The LAMP stack was configured mostly per: http://voidweb.com/2010/07/the-perfect-lamp-stack-apache2-fastcgi-php-fp...
However I likely deviated from the guide, so below are the relevant parts of my Apache config.
In /etc/httpd/conf.d:
php-fastcgi.conf
httpd.conf:
httpd-vhosts.conf:
While troubleshooting, I had all non-core modules, except Bad Behavior, disabled. If you still want the list of non-core modules anyways (despite being disabled), let me know.
Note that currently I have Bad Behavior turned off and all other modules turned on so that I can continue working.
Comment #31
vinoth.3v CreditAttribution: vinoth.3v commentedhere I am getting 'Header 'Referer' present but blank'
is disabling BB is the only way?
:(
Drupal 7, Nginx, APC, within proxy.
Comment #32
rahim123 CreditAttribution: rahim123 commentedI'm using a Webfaction host, which also uses Nginx on the frontend to forward requests to Apache. Could this have something to do with it?
Comment #33
Kutakizukari CreditAttribution: Kutakizukari commentedWebhost is http://bluehost.com shared environment. They did not know what I was talking about for the rest of the information you requested but I did dig up this:
Apache: 2.2.20
PHP: 5.3.18
MySQL: 5.5.28-log
Architechture: x86_64
OS: Linux
Kernel version: 2.6.32-20120131.55.1.b
The list of Drupal modules you have, which you can find with drush pm-list Attached
How I installed Drupal and Babbehavior
$ wget http://ftp.drupal.org/files/projects/drupal-7.17.tar.gz
$ tar –zxvf drupal-7.17.tar.gz
Went to http://8bitplayp.us/drupal with Firefox 17 and went through the install.
Then:
$ drush dl badbehavior
$drush en badbehavior
Went to http://8bitplayp.us/drupal with Chrome and get the error page.
Have the newer browsers been ruled out?
Comment #34
vinoth.3v CreditAttribution: vinoth.3v commented@sb56637
I am also using webfaction,
BB is working great on Drupal 6 site. I am having trouble only on drupal 7 site.
Comment #35
Luen Warneke CreditAttribution: Luen Warneke commentedsame problem.
Error 400
We're sorry, but we could not fulfill your request for / on this server.
An invalid request was received from your browser. This may be caused by a malfunctioning proxy server or browser privacy software.
Your technical support key is: 76d0-abf2-6992-0ee5
You can use this key to fix this problem yourself.
If you are unable to fix the problem yourself, please contact contact at example.com and be sure to provide the technical support key shown above.
Comment #36
error CreditAttribution: error commented@Luen, Please post the information requested (see comment 27).
Comment #37
gregarios CreditAttribution: gregarios commentedWill some of you try the complete zipped badbehavior module attached and report back? Make sure it isn't blocking you, and is still blocking spammers in the log. Thank you.
Comment #38
Kutakizukari CreditAttribution: Kutakizukari commented@gregarios
I removed the babehavior directory and the libraries directory and uninstalled from the modules section.
I unzipped and and transfered using SFTP and recreated the libraries directory with the newley transfered bad-behavior from the site.
Same results, still blocking me from Chrome and IE @ http://8bitplatyp.us/drupal
Comment #39
rahim123 CreditAttribution: rahim123 commented@ vinoth.3v (#34)
Ah, yes, I should have mentioned that I also run a Drupal 6 site on Webfaction with BadBehavior and it works fine. It's only the D7 site that has this error. But even so, I wonder if the Nginx passoff to Apache somehow affects the Drupal 7 implementation.
Comment #40
rahim123 CreditAttribution: rahim123 commented@ gregarios (#37)
I tried badbehavior7_mod_20121205a.zip, and it still gives me the same error. Thanks very much for looking into this error!
Comment #41
vinoth.3v CreditAttribution: vinoth.3v commented@ sb56637 (#39)
I have a separate nginx install on my account that handles both Drupal 6 & 7 sites. So I hope, it is not a issue of nginx/apache.
Comment #42
jlea9378 CreditAttribution: jlea9378 commentedFYI, I do not use nginx.
Comment #43
Luen Warneke CreditAttribution: Luen Warneke commentedPHP Version 5.3.13
Server API CGI/FastCGI
that's all I can tell you.
Comment #44
mmtahir CreditAttribution: mmtahir commentedI have the same error #14, #28..
I am uninstalling it untill some fix is found
Comment #45
uno CreditAttribution: uno commentedSame here, works perfectly (AFAIK) on d6, blocks me (and others) on d7 - same environment.
On d7, when BB enabled, if I am logged in I can access site, but when log out - error 400 (logged http://example.com - access, new tab http://www.example.com - no access.
Comment #46
error CreditAttribution: error commentedYour comments are 100% useless unless you read and follow the directions in comment #27. If you fail to do so, I will not be able to help you.
Comment #47
jstuckle CreditAttribution: jstuckle commentedI don't use this module, but I've seen similar behavior before. I believe the problem is the assumption the referer, if present, will contain a value. That is not true; it is perfectly valid for the referer field to be empty (yet still sent), i.e. when the URL is typed into the browser location field or a bookmark is used. When the page is accessed by clicking on a link from another page, the referer field will contain a value.
I tested this hypothesis. First I entered http://8bitplayp.us/drupal into the location field (FF 17) and got the above noted error. However, when I came back here and clicked on the link in post #38 above, I got to the login page. Looking at the headers, the first did not send any content in the referer header; the second one did.
Comment #48
error CreditAttribution: error commented@jstuckle According to RFC 2616 it is not valid for Referer: to be blank. If present, it must be either an absoluteURI or a relativeURI as defined in RFC 2396. It is valid for the header to be omitted entirely. If you've found that the _browser_ is sending a blank Referer: field, then it's a browser bug, and should be dealt with through that channel. But since this is only affecting Drupal 7, and not Drupal 6 or any other platform on which Bad Behavior runs, I suspect that is not the case.
Comment #49
Kutakizukari CreditAttribution: Kutakizukari commented@error
When it did work on drupal 6, at the time I was using an older browser.
Has anyone confirmed that the newer browsers have this problem with drupal 6 also?
Comment #50
vinoth.3v CreditAttribution: vinoth.3v commentedI can confirm this. I have both D6 and D7 sites running on nginx server behind proxy.
D6 site is working great. But D7 didn't.
I am using latest BB core and tested with FF 17.0.1 and Cromium 22 (Ubuntu 12.10)
Comment #51
jlea9378 CreditAttribution: jlea9378 commentedI'm being blocked on another one of my Drupal 7 sites which is hosted on a completely different server by Web Enabled. The site is a Drupal Commons 7 site (uses the latest dev release).
Drupal 7.18
Install profile Commons (commons-7.x-3.0-beta1+12-dev)
Bad Behavior 2.2.13
Database system version 5.1.41-gm2
PHP 5.3.6
Looks like it is a Red Hat EL5 server: 2.6.18-194.26.1.el5.028stab079.1.owl2
Running Apache. I think it is Apache 2.2.15-gm0
Server API CGI/FastCGI
I don't know how Apache and PHP were set up since this is a WebEnabled VPS, but I have root access so I can look in the config files if there is something specific you need me to check.
There are a dozen or so modules installed beyond what comes included in Commons 7, but they shouldn't be relevant based on my experiments with the other site (I was blocked even when using the default Garland theme with all modules disabled). However if you really want a list I can print my Available Updates pages to PDF or something. I don't have access to Drush.
Comment #52
Kutakizukari CreditAttribution: Kutakizukari commented@jlea9378 you can disable the module via drush to get back into the site:
Comment #53
jlea9378 CreditAttribution: jlea9378 commentedI don't have Drush. I used phpMyAdmin to disable badbehavior in the System table but that didn't stop me from being blocked. The only thing that stopped me from being blocked was to rename the library.
@error and @gregarios, I've provided information from two different environments that are having this problem, and some other people have responded with information as well. Any hope of getting this resolved soon?
From what I've seen, it seems to only be an issue on Drupal 7. It worked perfectly (as far as I know) on Drupal6. And it doesn't appear to be anything on the client end (people get blocked no matter what computer or browser they are using, even blocked when using Firefox on the web server's GUI.). It also doesn't appear to be related to other modules present since I still got blocked when using Garland with no modules enabled except BB. I haven't tried it on a FRESH install of Drupal 7 though.
Please let me know if you need more information from me or would like me to try something.
Comment #54
gregarios CreditAttribution: gregarios commentedI'd gladly fix it if I knew the cause.
Unfortunately, I didn't do the port to D7 and don't have any D7 installations to test it on.
If anyone out there can examine the version 7.x-2.x-dev Bad Behavior Drupal module code and come to a conclusion what is causing this, I'll patch it.
Comment #55
vinoth.3v CreditAttribution: vinoth.3v commentedAny update on this?
Comment #56
vinoth.3v CreditAttribution: vinoth.3v commentedSorry unable to findout why. Bad behavior :)
Comment #57
kduryee CreditAttribution: kduryee commentedWell, I have the same problem as everyone else on a site that's hosted at GoDaddy, (sigh). While I don't have anything really earth shaking to tell anyone, I did find that you can set up a whitelist of IP addresses in sites/all/libraries/bad-behavior. I haven't seen any mention of this handy back door; if you find yourself locked out of your own site and have access to files on the server, you can enter your IP address into the whitelist.ini and regain access to your site.
There is a file contained in the sites/all/libraries/bad-behavior directory called whitelist-sample.ini - change the name to whitelist.ini and then enter your IP address under the digg IP addresses here - I've replaced my own server IP's with x's here:
Hopefully this issue gets resolved.
Comment #58
vinoth.3v CreditAttribution: vinoth.3v commentedThe error on my end was, there was a empty Referer in http header!
Nginx + php-fpm
Comment #59
error CreditAttribution: error commentedThat is indeed the immediate cause. The real question is, where is the empty Referer header coming from? I have still not been able to reproduce this, nor did a quick grep of the Drupal source reveal any place that this header might be accidentally set.
Comment #60
Routh CreditAttribution: Routh commentedWell I'm chiming in here with the exact same issue being caused by blank headers in D7.
Drupal: 7.19
NGINX: 1.2.7-0ubuntu0ppa1~precise
PHP-FPM: 5.4
Macached: 1.4.13-0ubuntu2
PHP5-APC: 3.1.7-1
No proxies are in place on my server. Drupal Caching is active. NGINX uses a UNIX socket for communication with PHP-FPM. I have also noted that GoogleBOT and TwitterFeed are being blocked for the same reason, so it's not just users.
Drupal 7 Module list:
Comment #61
error CreditAttribution: error commentedI finally found the problem. There is actually a bug in the Drupal 7 core.
In function drupal_environment_initialize() in includes/bootstrap.inc, the first three lines are:
if (!isset($_SERVER['HTTP_REFERER'])) {
$_SERVER['HTTP_REFERER'] = '';
}
Referer, if present, MUST NOT be blank, according to RFC 2616, and so whatever reason this was put in for, it needs to be rewritten and/or removed. It interferes with Bad Behavior's check of the Referer value and offers absolutely no benefit to Drupal or anyone else, while inducing RFC-noncompliant behavior.
I presume this was added for Drupal's log entry, below in the same file, but there it is handled correctly, making this particular three lines of code redundant, useless and of course problematic. In fact the correct handling seems to be everywhere but modules/dblog/dblog.test which might fail in mysterious ways after this bug is fixed.
Those of you affected should try removing these erroneous lines of code to see if it causes any other issues.
Reassigning this to Drupal as it is a core issue and not a Bad Behavior module issue.
Comment #62
Luen Warneke CreditAttribution: Luen Warneke commentedYes, this works for me. I have not noticed any issues cause by this change in the drupal core code yet.
Thank you error.
Comment #63
rumblewand CreditAttribution: rumblewand commentedCommenting line 637 in bootstrap.inc worked for me as indicated in post #61. Should we update the title to reflect the bug?? "HTTP_REFERER" should not be blank" or something?
Comment #64
gregarios CreditAttribution: gregarios commentedWhat is the HTTP_REFERER variable before it gets assigned as "blank" in this case? Null?
Comment #65
error CreditAttribution: error commentedBefore this code sets it to the empty string, the key doesn't exist in $_SERVER. It's not meant to, since the HTTP server never sent it in the first place. And that's because in the case where it doesn't exist, the browser never sent it.
There's a significant semantic difference between the header not being sent, and the header being sent with an empty value. (Specifically, RFC 2616 bans the latter.) This may not be important to Drupal's log, which treats them both the same, but modules such as this one may rely on being able to detect the difference.
As suggested, I've changed the issue title and tags. (Regression, as this behavior was not present in Drupal 6, and Quick fix, since fixing it is a three line change that doesn't appear to break any functionality.)
Comment #66
jlea9378 CreditAttribution: jlea9378 commentedThanks for your diligence and effort in hunting down this bug, error!
Comment #67
phreadom CreditAttribution: phreadom commentedHas anyone reported this to drupal core so that we don't have to hack core? (since hacking core is the ultimate no-no in drupal development)
This did indeed fix the problem for me, but I'd really rather not have to change any of my core files.
Comment #68
Hancock Glen CreditAttribution: Hancock Glen commentedRan into the same issue.
If I did a search and found my site via link then I could get to it without being blocked. If I did a direct access, then I was blocked.
Not a programmer but I am behind cloud flare. I do get the IP addresses, I also am getting some visitors while badbehavior is on.
Not sure if that helps or not.
Comment #69
Anonymous (not verified) CreditAttribution: Anonymous commented#61 solves the problem!
Drupal core doesn't use HTTP_REFERER except in three places:
#1 bootstrap.inc function watchdog()
'referer' => isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '',
#2 statistics.module
'url' => isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '',
#3 simpletest actions_loop_test.module, function watchdog_skip_semaphore()
'referer' => $_SERVER['HTTP_REFERER'],
Case #1 and #2 are OK, because they use
isset()
and default to ''.However, notice how case 3# is a problem! It shoud also do
isset()
Attaching 2 patches. One patch for bootstrap.inc, another for simpletest. Does this need a review? Correct me if I'm wrong.
Comment #70
Anonymous (not verified) CreditAttribution: Anonymous commentedIndeed the first patch failed, exactly on the HTTP_REFERER in the simpletest.
Attached both in 1 patch.
Comment #71
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe same code exists in Drupal 8. Please port the patch there first.
Comment #72
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks. Attached the D8 devx patch.
Comment #73
Anonymous (not verified) CreditAttribution: Anonymous commentedAttached also the final Drupal 7 improved patch (includes
dblog.test
fixes)Comment #75
Anonymous (not verified) CreditAttribution: Anonymous commentedBack to D8 for test. Sorry, not used to this.
Comment #77
Anonymous (not verified) CreditAttribution: Anonymous commented#75: 1824360-72-bootstrap-http-referer-rfc2616-d8.patch queued for re-testing.
Comment #78
WiredEscape CreditAttribution: WiredEscape commentedAny further progress on this issue? I miss using Bad-behavior...
Comment #79
FSheFF CreditAttribution: FSheFF commented73: 1824360-73-bootstrap-http-referer-rfc2616-d7.patch queued for re-testing.
Comment #81
jollysolutionscan someone please fix this for drupal 7?
Comment #82
jlea9378 CreditAttribution: jlea9378 commentedPlease commit to D7. =(
Comment #83
coreyp_1 CreditAttribution: coreyp_1 commentedJust wanting to report that #73 worked just fine for my D7 site, although the patch had an offset for Hunk #1 of 4 lines (which may be why it is listed as "failed testing").
For those needing a quick fix, #73 is completely safe.
Comment #84
ParisLiakos CreditAttribution: ParisLiakos commented75: 1824360-72-bootstrap-http-referer-rfc2616-d8.patch queued for re-testing.
Comment #86
JieXiannn CreditAttribution: JieXiannn commentedHi, I'm a D7 user facing the same errors. Which patch should I apply? Is there a secure one?
Thank you.
Comment #87
jlea9378 CreditAttribution: jlea9378 commentedThe patch in comment #73 should work fine.
Comment #88
JieXiannn CreditAttribution: JieXiannn commentedSorry if i missed something but didn't #73 fail the test?
Comment #90
jlea9378 CreditAttribution: jlea9378 commentedI think it failed because the issue is set to Drupal 8, and that patch was for Drupal 7.
Comment #91
MixologicHere's a rerolled d8 patch.
Comment #92
ParisLiakos CreditAttribution: ParisLiakos commentedComment #93
MixologicHiding files
Comment #94
ParisLiakos CreditAttribution: ParisLiakos commentedbot agrees, this is good to go
Comment #95
catchCommitted/pushed to 8.x, thanks!
Comment #98
coreyp_1 CreditAttribution: coreyp_1 commentedThis was patched in 8.x (which, btw, was then removed entirely in the great kernel migration.
Unfortunately, it never made it into 7.x, where it is needed.
Comment #100
dcam CreditAttribution: dcam commentedI'm re-uploading #73 so Testbot won't continually re-test the 8.x patch in #91 when I set the issue to RTBC. I am not the author and the patch should not be attributed to me.
The changes are the same as what went into 8.x, with an additional change to another test. Once the patch is applied the code in bootstrap.inc is removed and all instances of $_SERVER['HTTP_REFERER'] in 7.x are checked with isset().
Comment #103
dcam CreditAttribution: dcam commentedComment #106
dcam CreditAttribution: dcam commentedComment #109
dcam CreditAttribution: dcam commentedComment #112
dcam CreditAttribution: dcam commentedComment #113
David_Rothstein CreditAttribution: David_Rothstein commentedThis will lead to PHP notices in various contrib modules that expect $_SERVER['HTTP_REFERER'] to be present.
Question: If the patch were changed to do
$_SERVER['HTTP_REFERER'] = NULL
rather than$_SERVER['HTTP_REFERER'] = ''
would that still solve the bug?Comment #114
BrettSh CreditAttribution: BrettSh commentedI tried changing this line:
$_SERVER['HTTP_REFERER'] = '';
to this:
$_SERVER['HTTP_REFERER'] = NULL;
Unfortunately, that change didn't fix the problem.
I'm running
- Drupal 7.35
- Bad Behavior module 7.x-2.2216
- Bad Behavior library 2.2.15.
So, pretty recent versions of everything. However, the only thing I found that fixes the problem is patch #73.
Comment #115
BrettSh CreditAttribution: BrettSh commentedJust out of curiosity, which contrib modules will generate the PHP notice when patched?
Also, what is the notice message?
Comment #116
xiaomo CreditAttribution: xiaomo commentedCould not apply the patch with git for the latest version of Drupal 7.x . Keep getting directory error. I can confirm patch is in the same directory as the file, weird.
Comment #117
izmeez CreditAttribution: izmeez commented@xiaomo for patches to drupal core the patch must be where your drupal core resides, the same folder as index.php
Comment #118
xiaomo CreditAttribution: xiaomo commentedOh, that might've been why. I just manually did it. Thank you for the info.
Comment #119
jollysolutionsComment #120
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI took a look through a couple codebases and found these possible examples:
http://cgit.drupalcode.org/twitter/tree/twitter_signin/twitter_signin.mo...
http://cgit.drupalcode.org/print/tree/print.pages.inc?h=7.x-2.0#n78
http://cgit.drupalcode.org/print/tree/print_mail/print_mail.inc?h=7.x-2....
I haven't tested those manually, but I assume there are others also.
I'm sympathetic to doing some kind of core fix here since it seems like it should not be an empty string, but setting it explicitly to NULL is a legitimate way in PHP of saying "the value does not exist" so it seems like that should be sufficient.
I took a look at the Bad Behavior library and it seems like the only reason that won't work is that it uses array_key_exists() rather than isset() in a couple places, for example common_tests.inc.php:
and post.inc.php:
I don't know if there's a good reason they need to use array_key_exists() over isset(), but if not then proposing an upstream patch to change that would help solve this.
Or if that's not feasible, it seems like the Drupal Bad Behavior module could deal with it just by unsetting an empty/NULL $_SERVER['HTTP_REFERER'] before calling into the Bad Behavior library (in fact, it could even do that with or without this core patch)?
Comment #121
error CreditAttribution: error as a volunteer commented@David_Rothstein, please see comments #48, #61 and #65.
Comment #122
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented@error, yup, but see what I wrote above:
If Drupal 7 weren't released yet it would be one thing, but a lot of code out there does seem to rely on this array key always existing and Drupal 7 has guaranteed that it exists for a long, long time...
Comment #125
jollysolutionsComment #128
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented#120 and #122 still apply. No answers to those, so I'm moving this back to "needs work".