Backdrop core has a feature that is not user-facing directly, often referred to as poor man's cron (link to documentation?). This feature triggers certain periodic tasks of a Backdrop site, like emptying log files, sending e-mails, and clearing out caches. This feature, when combined with dynamic detection of the $base_url, can lead to some potentially undesired situations. This article is a description of some of those situations, and what you can do to prevent them. The scenarios below assume some default configurations. At the end of this article there are some recommendations on how to break away from those defaults, in order to prevent these problems.
Scenario 1: Receiving/sending user emails that appear to be for another domain
This behavior is pretty easy to replicate:
- 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
- Visit the url: http://other-site.example.org/user/password
- Submit a username that is likely to be used on the site.
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 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. Two bad scenarios could come from this though:
- In a worst-case scenario, the user would click on the password reset link, which the evil site could then use to login to the main site as that user.
- They might enter their username/password into http://other-site.example.org (a so-called social engineering attack), which could then be used on the main site.
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 request happens to be the one 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. Backdrop 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 the wrong domain name, then notifications will be sent with that incorrect domain. Users will be very confused about why the mail they 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 Backdrop'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 the settings.php file. 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 file and let $base_url be detected dynamically. This has the implication of letting Backdrop respond to all subdomains of example.com which may or may not be required.
- Configure your webserver so that the default page served when an incoming request is something other than your default Backdrop installation, such as an error page.
- Configure your webserver so that all requests that reach your server that are not for the appropriate domain are forwarded/redirected to the right domain name.