Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
It turns out that IP(v4) addresses are 'valid' domain names, in the sense that they're made up exclusively of allowed characters, namely numerals and periods. However, if one were to create a site with an IP address for a name, it would be unreachable. The only exception(s) would be if the IP address in question was pointing to the Aegir server. But even there, the site doesn't work, and I don't think it's worthwhile exploring why.
So, I suggest that we add a form validation to ensure the site name is not an IP address.
Comments
Comment #1
omega8cc CreditAttribution: omega8cc commentedBut then you need to create separate validation for this, because now the same validation is used in other forms, where you edit legitimate IP used by server.
This means that you need an extra function like:
This should be used inside
function hosting_server_validate
instead of currentfunction _hosting_valid_fqdn
.Then you need to modify
function _hosting_valid_fqdn
, so it will not allow IPs, so something like:Note that I have added support for domain wildcards here and don't allow the dot at the end (even if it is valid from the DNS perspective), which may not work in Apache, but works great in Nginx, so you will need just:
Of course you will need to modify also
form_set_error
messages inhosting_site.form.inc
,hosting_migrate.module
andhosting_alias.module
, so it will say something like: "You have not specified a valid domain name. IP address is not allowed."Comment #2
ergonlogicI was actually thinking of just adding a validation for that form element that runs before the existing validation, so as to minimize the impact. Then just basically just throw an error if it matches an IP address. Mind you, I haven't looked at the site form for awhile...
Comment #3
omega8cc CreditAttribution: omega8cc commentedYou need this on the validation function level, not on the form element(s) level, so you can do this once and it will work in all forms - also for Aliases, Clone and Migrate etc.
Comment #4
anarcat CreditAttribution: anarcat commentedI don't get what the problem is here - there is validation for site names already, in the function _hosting_valid_fqdn(), called from various validate functions, see http://api.aegirproject.org/api/Hostmaster/modules--hosting--hosting.inc... for details.
Now as for allowing IP addresses, this is a side effect of allowing digits as the first characters in subdomains, something which was enabled about 4 years ago, in #317089: new site title/url generation purpose?, as some registrars do allow such domains to be registered, against RFC recommendations. We could complicate the regex by making sure (say) the last component doesn't start with a digit.
I wonder, though, what the problem is with having a site name be an IP address, can you expand on that?
(I believe that wildcard support should be processed in a separate issue, however. See #1193982: Wildcard subdomain support.)
Comment #5
omega8cc CreditAttribution: omega8cc commentedThis can be a problem when you have more than 1 client (like in the typical SaaS mode) hosted on the same instance, since any of them (and they will try that) can add the IP shared with others as "his own" alias, and display his website on this shared IP, while it could be used for something else, like Chive URL. Allowing this is something I don't like, but it is rather a matter of host policy, I guess.
Comment #6
anarcat CreditAttribution: anarcat commentedWell, there's a difference between allowing it on a specific server and completely disallowing users to use that (accidental) feature... I find it actually pretty nice that you can make aegir answer on IP addresses, maybe we just need to add this as an alias to the main @hostmaster site to forbid people from stealing it at first, but then I wouldn't even bother with that. :)
In any case, I guess we'd need a patch to move forward from here.
Comment #7
ergonlogicI'm not talking about something like '192.168.0.1.net', though I think that'd make a great vanity domain :P Really, it's naming a site '192.168.0.1' or similar.
I just tested this, and I couldn't login to such a site, either through the one-time login link, or by manually setting a password via drush.
Comment #8
anarcat CreditAttribution: anarcat commentedI understand the naming problem - the hostname being a real IP. I found that was a cool feature.
Now why doesn't it work? is it that cookies are not being set properly?
We still need a patch before this is needs review.
Comment #9
kunago CreditAttribution: kunago commentedThough it may prevent using an IP as a domain name, it prevents me from using my IDN. I tried cloning my site just recently (using Barracuda/Octopus, ver 2.0.5) and was notified I am not using a valid domain name which obviously is not true. Do please take IDNs into account as well.
Comment #10
anarcat CreditAttribution: anarcat commented@kunago - This issue is about site names being IP addresses. If you have other concerns regarding domain name validation, I encourage you to open a separate issue.
(I'm actually surprised we don't support internationalised site names... )
Regarding the original issue here, I think the current validation is sufficient, and unless there's a good case made against IP addresses being acceptable site names, I will simply close this issue...
Comment #11
Ken Hawkins CreditAttribution: Ken Hawkins commentedJust a heads up that there is a work around to use IP address "named" sites: #2013683: IP addresses break Aegir login, cookies
Comment #12
anarcat CreditAttribution: anarcat commentedalright, well if that's the only issue, let's followup there and close this non-bug.
Comment #13
omega8cc CreditAttribution: omega8cc commentedDrupal 7 explicitly doesn't set cookies for IP and localhost, so we should disallow this by default to avoid confusion. Reopening this, because I have closed the other feature request as won't fix: https://drupal.org/node/2013683#comment-7508015
Comment #14
anarcat CreditAttribution: anarcat commentedI think this is a silly mistake of Drupal core, but I am not sure I want to take up that bikeshed painting fest in the core issue queues.
I still think there's a case for Aegir to allow URIs to have IP addresses. At the very least, we should allow users to redirect from IP addresses to the main domain name.
Comment #15
ergonlogicThe 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open, or better yet, create a new issue referencing this one.