Drupal 7 added a new feature into core that is not user facing directly, but is sometimes called poor man's cron. The feature triggers the periodic tasks of a Drupal site like emptying log files, sending e-mails, and clearing out caches. This feature, when combined with dynamic detection of the "base url" (added in Drupal 4.7), can lead to some screwy situations. This article is a description of some of those screwy situations that occur with either module or both of them and what you can do to prevent them. The comments below assume some default configurations - I'll discuss at the end how to break away from those defaults to prevent these problems.
Scenario 1: Getting/sending user emails that appear to be for another domain
This behavior is pretty easy to replicate:
1. Point a new domain at the IP of an existing site - let's call the existing site http://www.example.com and the new name pointed at that IP is http://other-site.example.org
2. Visit the url: http://other-site.example.org/user/password
3. Submit a username that is likely to be populated
The result is that in step 2 the $base_url detection thinks that your site is http://other-site.example.org and all the tokens for the e-mail like [user:one-time-login-url]that contain links to your site will be changed to use http://other-site.example.org as the base url. The user who receives this email will see their username and e-mail for example.com are now somehow in use on http://other-site.example.org which is usually just confusing, but in a worst-case scenario could lead to them entering a password into http://other-site.example.org - a so-called social engineering attack.
Scenario 2: Cache entries containing the wrong domain
A similar problem can occur when a user uses the wrong domain to make a request and that happens to be the request that primes a cache entry with dynamic, fully qualified domains in it. Subsequent visits that retrieve information from that cache will get the wrong domain name. Drupal core's page cache uses the domain as part of the cache ID, preventing this problem, but other caching mechanisms may not be as robust against this problem.
Scenario 3: Notification mails containing the wrong domain
Yet another problem can occur on sites that use modules that send e-mails during cron runs. This scenario requires the poor-man's-cron with the dynamic base_url detection. If a user happens to trigger the poor man's cron when there are notifications in the queue by visiting using the wrong domain name then notifications will be sent with that incorrect domain. Users will be very confused about why the mail the expect to receive coming from an e-mail address at example.com includes links to the http://other-site.example.org domain.
Solutions to confusing experiences with Drupal's dynamic base_url detection
There are at least four potential solutions to this problem, though not all are necessary to stop the problem from happening. You should pick and choose as appropriate for your environment.
- You can set a specific domain as your $base_url in sites/default/settings.php. While the dynamic detection can be a handy feature it can also cause problems. One way to stop that is just to set a permanent value.
- Use a specific sites/example.com/settings.php and leave dynamic $base_url - this has the implication of letting Drupal respond to all subdomains of example.com which may or may not be a benefit.
- Configure your webserver so that the default page served when an incoming request is something other than your default Drupal installation, such as an error page.
- Configure your webserver to redirect all requests that reach your server that are not for the appropriate domain to forward to the right domain name.
This article is based on content from Drupal Scout: Your Drupal site pretending to be another? which is licensed Creative-Commons-Attribution-Share-Alike. That license is compatible with the drupal.org handbook license and this link is left as attribution to that article.
