Forum OpenACS Q&A: After upgrade, users unable to register

I just noticed that I haven't had any users register at the SAFE website since Feb 25th, when I upgraded my installation to 4.6.

It looks like when they hit the register link, which goes to /register, it redirects them to: http://www.safe4all.org/www.safe4all.org/register/

Looking at the code, I'm not really sure why it would do this. Any suggestions on where to look?

Collapse
Posted by Jade Rubick on
Weird. I have a section of the site that only certain people have permission to get to. If they go to that location:

http://www.safe4all.org/privatespace

Instead, they are redirected to

http://www.safe4all.org/www.safe4all.org/privatespace/

Which of course doesn't work.

Any suggestions?

Collapse
Posted by Jade Rubick on
Trying to access http://www.safe4all.org/hiddenlocation

From error.log:

[06/Mar/2003:20:24:50][18167.3076][-conn0-] Notice: Security: 9999999999 sec_generate_session_id_cookie setting 999999, 2539.
[06/Mar/2003:20:25:20][18167.6151][-conn3-] Notice: Security: 9999999999 sec_generate_session_id_cookie setting 999999, 0.
***[06/Mar/2003:20:25:20][18167.6151][-conn3-] Error: return: failed to redirect '404': exceeded recursion limit of 3

*** I think this is what's important.

Trying to access http://www.safe4all.org/register

This is the access.log

216.161.90.13 - - [06/Mar/2003:20:28:07 -0800] "GET /register/logout HTTP/1.1" 302 300 "" "Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)"
216.161.90.13 - - [06/Mar/2003:20:28:09 -0800] "GET /register/www.safe4all.org/
HTTP/1.1" 404 538 "http://www.safe4all.org/register/logout" "Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)"

Any suggestions of what else to do?

Collapse
Posted by Robert Locke on
I notice that if you add a trailing "/" (ie, http://www.safe4all.org/register/), then you get the proper registration page.

When I don't use the trailing "/", and attempt a telnet:

    $ telnet www.safe4all.org 80
    ...
    GET /register HTTP/1.1

    HTTP/1.0 302 Found
    ...
    Location: http://safe4all.org:8000/register/

So, it's redirecting to port 8000 of "safe4all.org".  Check your SystemURL parameter from ACS Kernel.  Or maybe your Tcl init file.

Hope these stabs in the dark help...

Collapse
Posted by Jade Rubick on
Thank you for the stabs :)

The SystemURL is http://www.safe4all.org

The system is actually on port 8000, but the router is directing it from port 80 to port 8000 inside the LAN.

When I first upgraded, the site actually went down because of this problem. For some reason, the ForceHostP was reset (I believe) to 1, so it would force all requests to go to port 8000. I set it to 0, and it worked.

So I guess my problem might be related to that. The easiest fix might just be to move the port, but this is a really strange error to get, and I have no idea of how to track it down.

Is this a request processor issue?

Collapse
Posted by Jade Rubick on
Okay, this is really weird.

I don't notice the problem in Safari, where I have a cookie with my login. I can go to anywhere I want.

I believe it was the same with Explorer, but when I logged out, and tried to log back in, I get that weird redirection error to

http://www.safe4all.org/register/www.safe4all.org/register/user-new?email=mylogin%40location%2ecom&persistent%5fcookie%5fp=1&return%5furl=%2f

So it doesn't seem to be a routing issue, right? If it was, it wouldn't work for all the static pages and for /news. And it wouldn't work for me, with my cookie to log in.

Could this be a bug in the new permission code? Don, perhaps something introduced in 4.6.2? I might have used the upgrade script to 4.6.2 on accident...

Actually, I'm embarrased to say... I think it's strange that it works at all. It's listening on port 8000, but the router doesn't seem to be forwarding the ports to 8000 from 80, only from 8000. I don't remember how I set it up.

Collapse
Posted by Robert Locke on
Hi Jade,

Ah.... well that explains it!

Looking at the telnet session above, here's what's appears to be going on:

  • The browser attempts to fetch "/register" without the trailing slash.
  • The server redirects to the directory "/register/". Since you're running on port 8000, it provides the fully qualified host name of "www.safe4all.org:8000", which seems to be the correct behavior.
  • The browser fails to connect to port 8000 (because your router's external interface is listening on 80) and appears to try a convoluted URL (that's the part I don't fully understand).

In any case, I'm not sure of a better solution, but I think it should work if you had the webserver listen on port 80 and had the router forward from port 80 to port 80.

And, for now, you can atleast change the register link on your home page and other pages to:
    http://www.safe4all.org/register/

Note the trailing slash. Click on the above link to see that it works..

Hope that helps!

Collapse
Posted by Tom Jackson on

What you need to get the server redirect correct is the following addition to your nsd.tcl file:

# If you want your web domain name to be www.example.com
# set up the following in you nsd.tcl file:
# ns_section "ns/server/${servername}/module/nssock"
# ns_param        port          8000 ;# Actual private port 
# ns_param        hostname      www.example.com ;# Internet Hostname
# ns_param        address       192.168.1.2 ;# Actual private ip
# ns_param        location      http://www.example.com ;# Protocol://Hostname
# The location parameter is essential for automatic redirects and for proper
# use of [ns_conn location], otherwise redirect would go to 
# http://www.example.com:8000
The example is from a tcl proxy module: tclvhr. You are essentially missing the location parameter.
Collapse
Posted by Jade Rubick on
Thanks for your help, everyone!

I set it up like this:

ns_section ns/server/${server}/module/nssock
ns_param   timeout            120
ns_param   address            192.168.1.5
ns_param   hostname           www.safe4all.org
ns_param   port               8000
ns_param location             http://www.safe4all.org

I also tried changing port to 80, and that didn't work either. Any other ideas?

Collapse
Posted by Tom Jackson on

So what does your telnet session to /register return now?

Collapse
Posted by Jade Rubick on
Thanks for your help, Tom.

I think I've narrowed down what the problem is. It's about halfway fixed.

Going to http://www.safe4all.org/register/ works now.

However, if I actually try to log in, using my name and password, I am still redirected to:

http://www.safe4all.org/register/www.safe4all.org/register/user-new?email=myusername%40myhost%2ecom&persistent%5fcookie%5fp=0&return%5furl=%2fpvt%2fhome

If I telnet...

[Jade-Rubicks-Computer:~] jade% telnet www.safe4all.org 80
Trying 216.161.90.13...
Connected to ddslppp13.ptld.uswest.net.
Escape character is '^]'.
GET /intl/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<TITLE>Redirection</TITLE>
</HEAD>
<BODY>
<H2>Redirection</H2>
<A HREF="http://www.safe4all.org/register/?return_url=%2fintl%2f">The requested URL has moved here.</A>
<P ALIGN=RIGHT><SMALL><I>AOLserver/3.3.1+ad13 on http://www.safe4all.org</I></SMALL></P>

</BODY></HTML>
Connection closed by foreign host.

If I look at the redirection for /register (without the trailing slash) it also doesn't work. Here's a telnet session:

[Jade-Rubicks-Computer:~] jade% telnet www.safe4all.org 80
Trying 216.161.90.13...
Connected to ddslppp13.ptld.uswest.net.
Escape character is '^]'.
GET /register
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<TITLE>Redirection</TITLE>
</HEAD>
<BODY>
<H2>Redirection</H2>
<A HREF="http://www.safe4all.org/register/">The requested URL has moved here.</A>
<P ALIGN=RIGHT><SMALL><I>AOLserver/3.3.1+ad13 on http://www.safe4all.org</I></SMALL></P>

</BODY></HTML>
Connection closed by foreign host.

Well, it seems like it should work, but it redirects to http://www.safe4all.org/www.safe4all.org/register/

So this is a redirection issue?

Collapse
Posted by Tom Jackson on

Well, using Netscape 7.0 on Win XP, if I go to /register, it correctly redirects me to /register/, so seems like it works. The redirection page also looks correct.

Collapse
Posted by Jade Rubick on
I've experimented with a couple of browsers.

It seems to be fine with Netscape on OS 9, Safari on OS X.

The redirect problem occurs on IE on OS 9 and IE on OS X.

Can anybody else try this for me?

Try going to:

http://www.safe4all.org/register  (without the backslash)

Does it redirect to http://www.safe4all.org/www.safe4all.org/register/

Can anybody think of a reason this would happen?

Collapse
Posted by Torben Brosten on
Hi Jade,

IE.5+ on MacOS has a bug where it doesn't redirect.  It just waits indefinitely. You might check to see if that's the case for the other one. Check it against a standard 404 redirect on another site.

Collapse
Posted by Jade Rubick on
The reason I don't think this is purely a Mac IE problem is:

1) This started happening immediately after I upgraded.

2) No users have registered since Feb. 25th. We usually get several a day. If this was strictly a Mac IE issue, many more would have registered.

The only thing I can imagine is maybe something I screwed up in the merged files from CVS. I think I'll go double check them.

Collapse
Posted by Michael Hinds on
Jade,

I get the same problem using IE6.0 on Win2k. I also experienced the same problem on one of my demo sites, but it appeared to be a result of installing a package I'm working on. When I deleted the package the redirection problem went away! I'm currently going through the code of my package to see if there's anything weird there. The demo site is using OACS4.6 and that's the only place I've seen with the problem. I'll keep you posted...

Michael

Collapse
Posted by Michael Hinds on
OK, it wasn't the package afterall. I've got as far as isolating the problem to /packages/acs-tcl/tcl/utilities-procs.tcl. I copied in the version from 4.5 as a quick fix.
Collapse
Posted by Jade Rubick on
Michael, how did you track that down? I'm impressed. I'll revert to the older version and see if that works.
Collapse
Posted by Jade Rubick on
Just a follow up, I think what the problem had been was that my upgrade hadn't worked. It had given me an error, but then when I went to the APM, it looked like it had upgraded. Don't assume it's worked if you get errors!

What I had to do is manually go in and execute each line in psql, to make sure the data model was correct.

Michael's fix did work. Later, however, I upgraded again, and it still works. That means either that file was corrected, or fixing the data model fixed things. It's probably a good idea to check both.

Collapse
Posted by Jade Rubick on
A follow-up, it's not working again. I think it might have occured during an upgrade to 4.6.3

I don't have the time to fix it now.

Collapse
Posted by Jade Rubick on
Reverting to the 4.5 version of /packages/acs-tcl/tcl/utilities-procs.tcl fixes the problem.
Collapse
Posted by Vinod Kurup on
Jade,

Take a look at this thread. Your symptoms seem similar to mine. I think the problem occurs when your server is on a nonstandard port and the browser is MSIE.

The patch I supplied fixed my problem.

Collapse
Posted by Jade Rubick on
Vinod helped me figure out what was going on here.

The patch is a good one to make, but it actually does not solve this problem. I suppose this is still a bug.

The problem is this:

My firewall redirects outside requests on port 80 to port 8000.

So inside, www.safe4all.org is listening on port 8000.

Outside, it listens on port 80.

The code doesn't redirect correctly for IE.

What I ended up doing, short-term, is hardcoding the port to 80.

I think the best solution would probably be an option in the config.tcl file, that utility-procs.tcl would read from, and override the default port.

Collapse
Posted by Vinod Kurup on
Here's what I think is going on.

  1. IE 6 exhibits the following buggy behavior. When it accesses a nonstandard port (i.e. not port 80) and then switches to SSL, it doesn't change the port in the Location header. That is, it should redirect from http://blah:8000 to httpS://blah:8443, but instead it redirects to httpS://blah:8000. I haven't tried to confirm this.
  2. CR Oldham patched util_current_location to take care of this. If both the following are true:
    • Server is running on a port other than 80
    • Client is MSIE
    then, the location will be built from scratch as follows:
    $proto://$host:$port
    
    • where $proto is determined from the driver being used. nssock=http, nsssl,nsopenssl=https
    • $host is determined from the Header supplied by the browser
    • $port is determined from the config file.
    It's acutally built with this regsub.
    regsub -nocase {(.*):.*} $host_from_header "$proto://\\1:$port" location_from_host_header
    
    What does this regsub do? It takes the $host_from_header, strips off the port at the end, and sticks it in between $proto and $port. It's important to note that it expects to find the colon in $host_from_header. That is, it expects a header like "abc.org:8000". If there's no colon, the regsub fails. This is important.
  3. This works fine except in the following case. When your server is on a nonstandard port, but the client thinks it's on port 80. This is Jade's situation (due to port forwarding) and mine (due to using AOLserver's virtual hosting). In this case, both conditions above will be true, but the client is requesting a location on port 80. Even though the server is running on a nonstandard port, the client doesn't know it. So the Host header will look like "abc.org". Look! No colon. Now the regsub fails and util_current_location returns a location like "abc.org" instead of "http://abc.org". This gets sent to ns_returnredirect which sees that it doesn't have a "http" at the front, so it slaps on the current location from the Host header, and you get the duplicate-looking URLs.
  4. How I would fix it. The MSIE bug only occurs in SSL, right? So, I propose that if the driver being used is nssock, then we don't do any URL mangling, but instead just use the Host from the HTTP headers like we used to. If we're using an SSL driver, we'll continue to fix the IE bug.
The patch is much simpler now:
RCS file: /cvsroot/openacs-4/packages/acs-tcl/tcl/utilities-procs.tcl,v
retrieving revision 1.19.2.19
diff -u -b -B -r1.19.2.19 utilities-procs.tcl
--- utilities-procs.tcl 7 Jun 2003 01:47:33 -0000   1.19.2.19
+++ utilities-procs.tcl 3 Sep 2003 03:50:41 -0000
@@ -2542,12 +2542,8 @@
    # Is this server running on a non-standard port?
    set nonstandard 0
    if { [ad_conn driver] == "nssock" } {
-       if { [ns_config -int "ns/server/[ns_info server]/module/nssock" Port 80\
] != 80 } {
-      set nonstandard 1
-      set port [ns_config -int "ns/server/[ns_info server]/module/nssock" Port\
 80]
-      set proto http
-       }
-
+       # MSIE bug only occurs in SSL. Don't mess with nssock connections
+       set nonstandard 0
    }

    if { [ad_conn driver] == "nsssl" || [ad_conn driver] == "nsssle" } {
Jade, would be able to confirm that this works for you? Does this make sense to everyone else?
Collapse
Posted by Vinod Kurup on
Sorry, the patch got a little mangled. Those long lines shouldn't wrap. Basically, if we're using nssock, we do nothing and let the Host Header dictate our location.
Collapse
Posted by Jade Rubick on
Thanks, Vinod! I'll test it out in the next week or so, and post what I discover.
Collapse
Posted by Frank Bergmann on
Hi Vinod, Jade,

isn't the parameter ForceHostP thought to determine this behaviour? Atleast it used to work like this in ACS 3.4.x.
Setting ForceHostP=0 meant that the server woudn't touch the client's header.

I'm running my first productive site on OpenACS 5.0 now with an external url of http://intranet.dnsalias.com:80/ and an internal URL of http://192.168.0.1:30018/, and coming from the "outside" I get redirected to http://intranet.dnsalias.com:30018/.

Bests,
Frank

mailto:frank.bergmann_at_project-open_doc_com
http://www.project-open.com/

Collapse
Posted by Randy O'Meara on
Hi Frank,

It's great that you've got your OpenACS site going. I see Arsdigita and Redhat mentioned, not OpenACS though...

/Randy

Collapse
Posted by Jade Rubick on
After my upgrade to OpenACS 5, I'm having a similar problem with non-standard ports. It appears that the util_current_location proc has been rewritten.

Here's Vinod's post about a closely related issue:

https://openacs.org/forums/message-view?message_id=107243

I'm trying to track down a solution to this.

Collapse
Posted by Jade Rubick on
Here's a hack I did on my OpenACS 5 install to get it to work:

Index: utilities-procs.tcl
===================================================================
RCS file: /var/cvs/safe4all/packages/acs-tcl/tcl/utilities-procs.tcl,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 utilities-procs.tcl
--- utilities-procs.tcl 1 Jun 2004 17:45:40 -0000      1.1.1.1
+++ utilities-procs.tcl 4 Jun 2004 04:31:11 -0000
@@ -2685,6 +2685,10 @@
        }
    }

+    # HACK TO WORK WITH NON-STANDARD PORTS, as per
+    # https://openacs.org/forums/message-view?message_id=84289
+    return "$proto://$hostname"
+
    if { ![empty_string_p $port] && ![string equal $port $default_port($proto)] } {
        return "$proto://$hostname:$port"
    } else {