0

In a Drupal installation, which is served through the web server's default server config (i.e. it gets any request for an otherwise unknown domain) I have a settings file at DRUPAL_ROOT/sites/example.com.au/settings.php.

This site is normally requested as http://example.com.au/, but what's given that the request gets to the server (and the user agent may not follow the directives of DNS here), what's to prevent it being served as a response for http://example.com/au/ or http://example/com/au/?

The testing I've done suggests something blocks this from working (I get a redirect to the install page), but I want to be clear on what's going on, and to be sure that it's reliable.

If accessing a drupal installation through divisions of the domain name and path other than the expected one is possible, then there would be security implications.

EDIT:

In response to @tenken:

From https://api.drupal.org/api/drupal/sites!example.sites.php/7

This file allows you to define a set of aliases that map hostnames, ports, and pathnames to configuration directories in the sites directory. These aliases are loaded prior to scanning for directories, and they are exempt from the normal discovery rules. See default.settings.php to view how Drupal discovers the configuration directory when no alias is found.

It's not perfectly clear, but that sounds like the directory in the sites file will will still be used if a request arrives with a domain name that was not anticipated, in which case the problem remains.

Improve this question

1 Answer 1

Reset to default
2

Your virtual host rules are as secure as you've written them. If you want complete control on what URLs map to what multi-site installations then use the sites.php placed in sites/sites.php of your sites folder to explicitly set what URL(s) go to which Drupal installation using PHP.

The sites.php file resolves the URL -> site mapping after the webserver directs traffic to Drupal.

EDIT

Drupal can be run in multi-site or standalone. This is accomplished on how you configure your webserver. The "problem" you're describing is you want to use multi-site but not have Drupal try to discover invalid site addresses. This is purely dependant on how you setup your webserver.

An example of how to setup Apache for multisite might be:

<VirtualHost *:80>
  ServerName example.com
  ServerAlias *.example.com
  DocumentRoot /var/www/example.com
</VritualHost>

This will resolve example.com to the docroot and any subdomain site at *.example.com -- including "invalid" subdomains which may not exist and attempt to route to an invalid url as you've described. This is by design by Drupal when using multi-site installation.

How might this be fixed for Apache? By fixing Apache vhost entries to limit what valid domains the virtual host is used for. This is not necessarily fixable via Drupal (although I still like using sites.php personally).

For instance we can change our virtualhost to the following:

<VirtualHost *:80>
  ServerName example.com
  ServerAlias site1.example.com abc.example.com xyz.example.com example
  DocumentRoot /var/www/example.com
</VritualHost>

This revised Apache virtualhost routes example.com and exactly 4 subdomains and no others to the docroot. No other domain traffic will be routed to this drupal installation from the webserver.

A similar technique should be available for most webservers. Your virtual host rules are as secure and as organized as you've written them for your own production servers. I use Nginx as a proxy for Apache on a few websites, and Nginx as the sole webserver for at least 1 site, but I haven't had to try to solve this problem myself using only Nginx (but I'm familiar with the Apache solution above).

Improve this answer
5
  • I'm using nginx, so no .htaccess files. The difficulty is that every rule that would normally be anchored to the start of the path might be subverted by extra junk at the start of the path, or bits removed from that path. I'll look into sites.php suggestion.
    – mc0e
    Dec 17, 2014 at 6:38
  • tenken is right: the domain name section of the request is handled by your virtual host(s). There's a couple of ideas that might help on this page.
    – Darvanen
    Dec 17, 2014 at 7:46
  • @mc0e as @Darvanen mentions you can create a default_server for example any unknown traffic will goto. It sounds like that's a pretty simple solution for you to send unknown traffic too nginx.org/en/docs/http/ngx_http_core_module.html#listen I would still consider using sites.php for firm control on the drupal side of your web stack. I also would recommend mentioning things like "I'm using Nginx" when providing details of your original post -- or else we have no clue what infrastructure your using is and our help is misguided.
    – tenken
    Dec 17, 2014 at 22:21
  • @tenken I'm using a default server in nginx. This issue would not arise otherwise. I've edited the question a little, improving the language describing this. It doesn't make much difference here whether I'm using nginx or apache or something else. The point is that requests for unknown domains get routed to a default drupal installation. I'm not concerned with the handling of expected modes of access, but rather unexpected ones, so it appears the sites.php mechanism is of little help - if the site is not defined in sites.php, the search of the sites/*/settings.php files still occurs.
    – mc0e
    Dec 19, 2014 at 7:14
  • @Darvanen see my post Edit. perhaps it will help you with Nginx, but i'm not sure.
    – tenken
    Dec 19, 2014 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.