Forum OpenACS Development: system vs. site name

Posted by Jeff Rogers on

When a user signs up to a site they get a welcome email (I have email confirmation for new users turned on). The email welcomes them to the site, however, it welcomes them to the top-level server and not to the subsite they registered on. I have multiple subsites using host-node mapping, and while users/logins could be shared across the subsites, the users should be kept on the site they registered on.

The login email welcomes them to and gives a link to the server - which has a completely different name - rather than the subsite. This is confusing, to say the least.

I think nearly all uses of ad_system_name should be replaced with subsite::get_element -element instance_name; and likewise ad_url should be replaced with subsite::get_url -absolute t. The only times you wouldn't want this are when you specifically want to refer to the server (probably only of interest to admins) or if you are not operating within a subsite context, e.g., when sending scheduled email; and even in that case it would be really useful to set up a subsite context.

Does this make sense?

2: Re: system vs. site name (response to 1)
Posted by Gustaf Neumann on
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?