Home
The Toolkit for Online Communities
17107 Community Members, 0 members online, 2429 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : ACS4.2 domain-based subsites working

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

Icon of envelope Request notifications

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

Collapse
Posted by Alex Sokoloff on
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.
Collapse
Posted by Jeff Putsch on
My experience is that it is basically working, but there is still something wrong. Here are the details:
  1. I must run my site off of port 8080 because my ISP blocks port 80 on incoming requests.
  2. Using site-map, I create a subfolder off of / called "OakmontReunion".
  3. I use the host-node-map (/admin/host-node-map) to map "oakmontreunion.dyndns.org" to have a root url of "/OakmontReunion/"
  4. 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.
Collapse
Posted by Don Baccus on
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.
Collapse
Posted by Jeff Putsch on
Here's a patch that appears to fix the problem.
<p>
I added a routine called &quot;ad_proc&quot; that will return the port portion of the request (including the leading &quot;:&quot;) and then modified the second case
in &quot;rp_filter&quot;.
<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 (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>

Collapse
Posted by Don Baccus on
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!)

Collapse
Posted by Tom Jackson on

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.