Closed (outdated)
Project:
Security Review
Version:
7.x-1.1
Component:
Documentation
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
27 Nov 2013 at 22:44 UTC
Updated:
8 Jan 2023 at 02:44 UTC
Jump to comment: Most recent
Comments
Comment #1
coltraneAre you using something like Domain Access to provide sub-domains served from same code and db?
Comment #2
denix commentedno, a mix of htaccess, apache and sites.php configuration
Comment #3
coltraneOk, if you can detect in settings.php the correct site being served then you could conditionally set $base_url.
Or if your specific configuration protects against a incorrect host header from loading any one of your sites than you're probably at low to zero risk of the issue that this check is intended to help with.
Comment #4
hometowndirectories commentedi've set the base_url to my site, but when i run security review it's still telling me to set the base url. i've double checked but i must be missing something. i thought it was as easy as changing sites/default/settings.php
Comment #5
rudetrue commentedIf you have the
$base_urlset and the test is failing, try the setting mentioned here: https://drupal.org/node/2001092#comment-7755321In my case I am using an
@includein settings.php, which pulls in a local.settings.php file (containing the$base_url). The review/test will fail for this configuration if you use the default "Tokenize settings.php" setting. You have to change it to "Include settings.php", which will execute the@import, or for others the conditional statements to set the correct base url. Maybe that setting should be mentioned in the failure message?You can switch the setting back and forth via drush with the following two commands:
Or through the Drupal admin pages:
Security Review -> Settings -> Advanced -> Check-specific Settings
I'm not sure if there are negatives to using the include setting, but there must be some drawbacks since the token method is recommended. I think it would just be an (unnoticeable?) performance decrease when running the Security Review; can someone confirm?
Comment #6
coltrane#5 @rudetrue, the include method can be risky because it may redefine global scope functions or execute custom settings.php functions should they exist (such as including a separate settings.php file as you've done). The token method is recommended only because it reduces any risks. If include works for you then great, but Security Review defaults to a less risky method.
The module configuration page mentions these differences tho it could be expanded to the check help page. I'll update this issue to be about that.
Comment #7
ckosloff commentedI am getting a false positive with recommended settings and I have no multisite, just one settings.php set to read only.
Comment #8
jshimota01 commentedOn my production server I want my site forced to use the domain name as recommended for security purposes. In settngs.php I set $base_url to 'http://www.xyz.com' /no trailing.
All worked fine except occasionally I would get lazy and enter 'xyz.com' into my browser and certain features would break. While reading the little there was on BaseURL in drupal help, I did see a dialog about someone fighting with .htaccess.
That reminded me about the ReWriteCond. So that my site worked as expected I edited my .htaccess and found already there, this following:
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# uncomment the following:
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# I un-commented the 3 lines above
This provided me both the lazy and the proper URL function on my site. Hope this helps someone.
Shu
(added - This assumes your DNS pointers both take you to the site!)
(added #2 - also, when you bring your site for localhost/dev work you must comment out $base_URL)
Comment #9
smustgrave commentedI know D7 is still alive but looking to clean the queue and move toward only
supporting modern version of Drupal.
The 7.x version of this module will essentially be O&M mode and still covered
for security and anything that comes through. If anyone wants to work on
these tickets they can but closing for now.