I get this message when I run security review. While it is clear how to set base_url in a standard installation, what is the expected configuration for sites like wikipedia having:
en.wikipedia.org
fr.wikipedia.org
and so on?

Comments

coltrane’s picture

Are you using something like Domain Access to provide sub-domains served from same code and db?

denix’s picture

no, a mix of htaccess, apache and sites.php configuration

coltrane’s picture

Ok, 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.

hometowndirectories’s picture

i'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

rudetrue’s picture

If you have the $base_url set and the test is failing, try the setting mentioned here: https://drupal.org/node/2001092#comment-7755321

In my case I am using an @include in 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:

drush vset security_review_base_url_method include
drush vset security_review_base_url_method token

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?

coltrane’s picture

#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.

ckosloff’s picture

I am getting a false positive with recommended settings and I have no multisite, just one settings.php set to read only.

jshimota01’s picture

On 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)

smustgrave’s picture

Status: Active » Closed (outdated)

I 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.