I fully agree that registration mail and instance name handling has room for improvement, but it is not so easy to be handled as sketched above. We have also the "security::get_register_subsite", since not every subsite allows registration, and the concerned emails should point to the registration subsite...
There are many places, where ad_system_name and ad_url are used, but one has to go into details, what is really needed at which place. I am writing this mail for me to recap the current situation with its pros and cons.
A problem with mail-sending is that this has to work without a connection. Therefore, the "host:" header field is not available, which of crucial for virtual host handling. The situation is even worse, when the server is running behind a proxy. In these situations, "subsite::get_url -absolute t" won't return a desired result (also "ad_conn behind_secure_proxy_p" and "ad_conn behind_proxy_p" require a connection), it it will contain the port behind the proxy.
So, for host-node-mapped subsites, one can get for a subsite_id quite easy the host-node-mapped hostname, but the desired protocol schema (HTTP vs. HTTPS) is not there. For other subsite_ids, it is not sure, we have the "right" hostname.
When we have the hostname, we could search for it the "ns/module/nsssl/servers" section, and assume when we find it for multiple network drivers that the secure one is the preferred. But then there is still the question with the port number (what is the right port number in this case). We could say, when "reverseproxymode" is configured, we omit the port (for this subsite_id). ... These are two assumptions, which will not fit all the unspoken requirements.
So, to address this, we could add an optional parameter for package instances named "SubsiteLocation" (consisting of protocol + host + port). This parameter could be used to override the heuristic above. For many users, this will work out of the box, some users have to override. ... but since this would be a new parameter, not many "old" users will do this.
Alternatively, we can extend the host-node map to include the full location (instead of the hostname like now), then there is a single place to look at (including the main site), ... but one might wish to run a host-node mapped subsite with multiple protocols (and ports), so this might be misleading, and we are rather back at parameters for subsite like "SubsiteMailURL" and a "SubsiteMailName".
Other ideas, comments, thoughts?
