Forum OpenACS Development: ACS4.2 domain-based subsites working

Posted by Michel Henry de Generet on 11/07/01 04:55 PM

Hello, I eventually try to install in ACS4.2 an old module (ACS4.0) which claim to resolve the famous problem of adding additional domain names that point to the same IP as the main domain name of your server and to map these domain names to site nodes (i.e. directories) of your web site.

This piece of software was written by Mark Dettinger of AD. Basically one new table is created, some admin pages are added and the main request processor is modified.

After some basic tests it seems to work. GREAT

Should the permission on the subsite not allow public read, the system would not link the user to the login page and an error is displayed on the browser. Also each subsite could only be linked to one domain name.

Should you need more information let me know. Michel

2: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Alex Sokoloff on 11/07/01 09:25 PM

That patch was ported and rolled into the openacs a couple of weeks back -- you should see it there and working in the Alpha tarball.

3: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Jeff Putsch on 11/08/01 01:08 AM

My experience is that it is basically working, but there is still something wrong. Here are the details:

I must run my site off of port 8080 because my ISP blocks port 80 on incoming requests.
Using site-map, I create a subfolder off of / called "OakmontReunion".
I use the host-node-map (/admin/host-node-map) to map "oakmontreunion.dyndns.org" to have a root url of "/OakmontReunion/"

I try to visit the "http://oakmontreunion.dyndns.org:8080/register" URL and get redirected to the wrong place. Using "wget" to show the sequence of redirects clearly indicates the problem:

wget http://oakmontreunion.dyndns.org:8080/register
--16:01:25--  http://oakmontreunion.dyndns.org:8080/register
           => `register'
Connecting to oakmontreunion.dyndns.org:8080... connected!
HTTP request sent, awaiting response... 302 Found
Location: http://oakmontreunion.dyndns.org:8080/OakmontReunion/register/ [following]
--16:01:32--  http://oakmontreunion.dyndns.org:8080/OakmontReunion/register/
           => `index.html'
Connecting to oakmontreunion.dyndns.org:8080... connected!
HTTP request sent, awaiting response... 302 Found
Location: http://oakmontreunion.dyndns.org/register/ [following]
--16:01:32--  http://oakmontreunion.dyndns.org/register/
           => `index.html'
Connecting to oakmontreunion.dyndns.org:80... ^C

It looks like the request processor is loosing the port information in one of it's redirects. I'll try and locate the problem, but if any of the core team gets there first I would be quite gratefull. Jeff.

4: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Don Baccus on 11/08/01 02:27 AM

It would be great if you'd track this down. If it uses the ns_conn proc to grab the port, in older versions of AOLserver, at least, this didn't work. Haven't tried it in AOLserver3.3+ad13, nor have I looked at the request processor to see how it's parsing out the host/port information.

5: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Jeff Putsch on 11/08/01 03:20 AM

Here's a patch that appears to fix the problem.
<p>
I added a routine called "ad_proc" that will return the port portion of the request (including the leading ":") and then modified the second case
in "rp_filter".
<pre>
--- openacs-4/packages/acs-tcl/tcl/request-processor-procs.tcl Thu Oct 18 14:49:45 2001
+++ openacs4/packages/acs-tcl/tcl/request-processor-procs.tcl Wed Nov 7 17:50:19 2001
@@ -5,7 +5,7 @@

@author Jon Salz (mailto:jsalz@arsdigita.com)
@date 15 May 2000
- @cvs-id $Id: request-processor-procs.tcl,v 1.6 2001/10/18 21:49:45 donb Exp $
+ @cvs-id $Id: request-processor-procs.tcl,v 1.1.1.1 2001/10/30 06:06:55 nsadmin Exp $
}

#####
@@ -367,10 +367,10 @@
}
if {[ad_secure_conn_p]} {
# it's a secure connection.
- ad_returnredirect https://[ad_host]$url
+ ad_returnredirect https://[ad_host][ad_port]$url
return "filter_return"
} else {
- ad_returnredirect http://[ad_host]$url
+ ad_returnredirect http://[ad_host][ad_port]$url
return "filter_return"
}
}
@@ -1024,6 +1024,18 @@
return $host
} else {
return "unknown host"
+ }
+}
+
+ad_proc ad_port {} {
+ Returns the port as it was typed in the browser,
+ provided forcehostp is set to 0.
+} {
+ set host_and_port [ns_set iget [ns_conn headers] Host]
+ if { [regexp {^([^:]+):([0-9]+)} $host_and_port match host port] } {
+ return ":$port"
+ } else {
+ return ""
}
}

</pre>

6: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Don Baccus on 11/08/01 05:03 AM

This is good (though you mean you've added "ad_port", and haven't replaced the very useful "ad_proc" :) I'm still wondering about AOLserver's ability to return the port natively. Nitpicking, I was annoyed by the API not working correctly and wonder if it works correctly today.

(Yes, I could check this myself, but I might ask you to take on a few of my existing OpenACS tasks as compensation if you ask me to do it!)

7: Response to ACS4.2 domain-based subsites working (response to 1)

Posted by Tom Jackson on 11/08/01 06:36 PM

It seems strange that the request processor would discard the :port part of the Host header. The :port is important. Obviously for a webserver a different port could be a completely different server. It is probably too late to do much with the current behavior, they should have called the ad_conn variable 'hostname', not host. Then it might have been more obvious what data the var contains. One allowable would be lowercasing the data, in case the browser doesn't do that.