Site appearance is sensitive to www, non-www or IP-address access to site [#2848395]

I am running a D7 website on an Ubuntu 12.04 VPS (yes, yes, I know, I am in the process of migrating to a newer distro).

Through .htaccess I have set the "www" requests to resolve to the "non-www" version of the site and I have observed the following strange behavior:

For a short time, due to a migration, my registrar had a broken DNS database, so my website was only accessible through its IP address. This entirely broke the theme. The site was still accessible and functioning if you knew the IP address, but it looked horrible. Once the DNS records were corrected, so was the appearance of the site.
Probably due to an oversight during an update, I left the default .htaccess file, so the "www" site was once again accessible. In that case, the site looked correct, and the theme was functioning, but the fonts were not correct.

I cannot even start to imagine why domain name resolution would affect a theme and fonts appearance.

Some more details:

In my install, I use a bought theme which I have installed at sites/all/themes/mytheme, and which I have used to create my sub-theme at sites/all/themes/mytheme_subtheme.
For fonts, I use @font-your-face, and I have locally uploaded all necessary
The $base_url value in my settings.php file is the non-www, i.e.
```
$base_url = 'http://mysite.org';
```
PHP 5.6 and 7.0 gave the same behavior
MySQL 5.5.53 (currently) but issue may have impacted previous updates
I use the securepages module to direct traffic to http (visitors) and https (admin) pages
Currently on D7.52 downloaded with drush, but issue impacted several previous versions

Comments

Comment #1

31 January 2017 at 13:08

thanasis57 created an issue. See original summary.

Comment #2

thanasis57 CreditAttribution: thanasis57 commented 31 January 2017 at 13:10

Title:

Appearance sensitive to www, non-www and IP access

» Site appearance is sensitive to www, non-www or IP-address access to site

Comment #3

thanasis57 CreditAttribution: thanasis57 commented 31 January 2017 at 22:29

I believe the problem may be related to cross-site sharing of resources, since the "www" site must share the fonts of the non-www one, and the browsers don't like that.

Posts:
http://stackoverflow.com/questions/1653308/access-control-allow-origin-m...
http://stackoverflow.com/questions/2892691/font-face-fonts-only-work-on-...
http://stackoverflow.com/questions/5008944/how-to-add-an-access-control-...

deal with using .htaccess declarations and css to solve the issue, but I can't understand the finer details.
-Is the .htaccess the global .htaccess or a local file for the /sites/default/files/fontyourface/local_fonts directory?
-Similarly, is the css file sites/all/themes/mytheme_subtheme/css/mytheme_subtheme.css or sites/default/files/fontyourface/fonts.css?

Comment #4

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard at Palantir.net commented 5 February 2017 at 15:21

When using domain access, you cannot hard code $base_url. This is documented in the INSTALL.txt.

Comment #5

thanasis57 CreditAttribution: thanasis57 commented 6 February 2017 at 13:47

Many thanks for the comment Ken. I guess I did some overkill with this one.

In my case I actually had a declaration:

if (!empty($_SERVER['HTTPS'])) {
ini_set('session.cookie_secure', 1);
$base_url = 'https://mysite.org';
}
else {
$base_url = 'http://mysite.org';
}

to control access to the http and https versions of the site.

I guess this is redundant and I need to comment it out to leave control to .htaccess.

Comment #6

thanasis57 CreditAttribution: thanasis57 commented 6 February 2017 at 14:05

Did it and the problems seem to have been solved.

Again, many thanks.

PS: I know the line was already commented out, and that a comment was telling users to look .htaccess for more information. My bad, user error 100%. Even so, might an even more explicit comment be useful? Just saying...

Comment #7

thanasis57 CreditAttribution: thanasis57 commented 28 February 2017 at 12:43

I have another question regarding this issue.

Now that I have commented out the $base_url declaration, when I run the Security Review module I get the warning:

Drupal base URL

Setting Drupal's $base_url in settings.php can help protect against attackers manipulating links to your site. For example, an attacker could exploit a missing $base_url setting to carry out a phishing attack that may lead to the theft of your site's private user data.

Your site is available at the following URL: https://mysite.org.

If your site should only be available at that URL it is recommended that you set it as the $base_url variable in the settings.php file at /var/www/drupal/sites/default/settings.php

Or, if you are using Drupal's multi-site functionality then you should set the $base_url variable for the appropriate settings.php for your site.

Not being a professional admin, I have to ask: is that a real risk, or somewhat inflated by the module authors?
If that risk is real, does that mean that using .htaccess for access control is an inherently unsafe practice and that Apache should be only configured though virtual hosts?