Tom,

The problem is that when ad_returnredirect is using ns_respond instead of ns_returnredirect, cookies don't work. When you try to log in, you just keep getting sent back to the login page. And if you try to put something in your cart, you get the message about cookies being disabled. Since the change doesn't affect the cookie's being set in the first place, my assumption is that it's not making it intact through the redirect.

janine

On Feb 17, 2006, at 10:24 PM, Tom Jackson wrote:

Janine,

But when I send the telnet request, with the Cookie: header, I get the same thing as when I use a browser. The target page test2.tcl doesn't include the
Set-Cookie header in response.

Is this what you want to happen or not?

Here is what I think is happening:

The client sends a request with a Cookie header (not Set-Cookie), so OACS knows who the user is. For some reason, this causes OACS to not include a
Set-Cookie header for return to the client.

I'm still not quite sure what the actual problem is that caused you to look
into this, so maybe there is another issue besides this one.

But the browser is working exactly like telnet if you include the Cookie header with the telnet request for test2.tcl. Nothing is wrong with the way
the browser is working.

But I think that OACS should probably be updating the cookie value so that the new expiration time will take effect. What code is deciding when to set the header? If OACS doesn't do this update, then eventually the 1200 seconds will expire and the browser will no longer send that cookie. At that point OACS will issue a new cookie and probably force the user to login again. Is that
the behavior you are seeing?

tom jackson

On Friday 17 February 2006 18:30, Janine Sisk wrote:
I may have started you on the proverbial wild goose chase with this
cookie stuff, so let's start over.

There are two main differences between a page sent to the browser via
ns_returnredirect vs one sent by ns_respond.  ns_returnredirect puts
together a small HTML page and sends it off to the browser with
content type text/html, using the header data that's already in the
conn data structure.  ns_respond takes the set of headers passed to
it, replaces the headers in conn with the ones that are passed in,
and then sends the string off to the browser.  So the two significant
differences are the handling of the headers, and that
ns_returnredirect sends a properly formed HTML page whereas my use of
ns_respond sends only the word "Redirect".  My hunch is that the
former is the problem.

So could there be something about the way the -headers argument to
ns_respond is handled that is somehow garbling the data?  Could Tcl
be doing something to it as it's being passed along?

janine

On Feb 17, 2006, at 6:03 PM, Tom Jackson wrote:
Janine,

Now I'm getting confused. If the browser or the telnet sends the
cookie it
just received, the outputheaders on test2.tcl don't include a set-
cookie
header. So it isn't in the outputheaders I guess. I just did this:

[EMAIL PROTECTED]:/media/floppy> telnet temp.nybooks.com 80
Trying 209.162.194.75...
Connected to temp.nybooks.com.
Escape character is '^]'.
GET /test.tcl HTTP/1.0
Host: temp.nybooks.com

HTTP/1.0 302 Found
Host: temp.nybooks.com
Set-Cookie:
ad_session_id=80111104%2c0+%7b663+1140228924
+1E0DA0457345E6F9CE3F6D34E60EA76197B8858D%7d;
Path=/; Max-Age=1200
location: http://temp.nybooks.com/test2.tcl
MIME-Version: 1.0
Date: Sat, 18 Feb 2006 01:55:24 GMT
Server: AOLserver/4.0.10
Content-Type: text/plain; charset=iso-8859-1
Content-Length: 8
Connection: close

RedirectConnection closed by foreign host.
[EMAIL PROTECTED]:/media/floppy> telnet temp.nybooks.com 80
Trying 209.162.194.75...
Connected to temp.nybooks.com.
Escape character is '^]'.
GET /test2.tcl HTTP/1.0
Host: temp.nybooks.com
Cookie:
ad_session_id=80111104%2c0+%7b663+1140228924
+1E0DA0457345E6F9CE3F6D34E60EA76197B8858D%7d;

HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/html
Server: AOLserver/4.0

ns_conn headers - size = 2<br>
key = Host, value = temp.nybooks.com<br>
key = Cookie, value =
ad_session_id=80111104%2c0+%7b663+1140228924
+1E0DA0457345E6F9CE3F6D34E60EA76197B8858D%7d;<br>
<p>
ad_conn headers - size = 2<br>
key = Host, value = temp.nybooks.com<br>
key = Cookie, value =
ad_session_id=80111104%2c0+%7b663+1140228924
+1E0DA0457345E6F9CE3F6D34E60EA76197B8858D%7d;<br>
<p>
ns_conn outputheaders - size = 1<br>
key = Server, value = AOLserver/4.0<br>
<p>
ad_conn outputheaders - size = 1<br>
key = Server, value = AOLserver/4.0<br>
Connection closed by foreign host.

My browser shows the same behavior as telnet. OACS isn't filling the
outputheader with the set-cookie if the browser/client has a cookie.

tom jackson

On Friday 17 February 2006 17:35, Janine Sisk wrote:
Well no, I'm not sure that it sends the Set-Cookie header on every
request.  But something about the change I made is causing OACS to
act as though the browser has cookies turned off, so I kind of zeroed in on that. If there are other things that could cause that symptom
I should look at those too, I just didn't know what they might be.

janine

On Feb 17, 2006, at 5:24 PM, Tom Jackson wrote:
Janine,

I would try the second request via telnet, but send the cookie
value you
received on the first request. Are you sure that OACS sends the Set-
Cookie
header on every request? Maybe it doesn't do it since the cookie is
already
there?

tom jackson

GET /test.tcl HTTP/1.0
Host: temp.nybooks.com
Cookie:
ad_session_id=80111002%2c0+%7b542+1140224229
+57E9A3EA3E33AB40F47F8EA71184A3D012E347ED%7d;

On Friday 17 February 2006 16:44, Janine Sisk wrote:
OK, so here we go.  test.tcl contains a single line, a call to
ad_returnredirect, which has been modified to use ns_respond
instead
of ns_returnredirect.

GET /test.tcl HTTP/1.0

HTTP/1.0 302 Found
Set-Cookie: ad_session_id=80111002%2c0+%7b542+1140224229
+57E9A3EA3E33AB40F47F8EA71184A3D012E347ED%7d; Path=/; Max- Age=1200
location: http://temp.nybooks.com/test2.tcl
MIME-Version: 1.0
Date: Sat, 18 Feb 2006 00:37:09 GMT
Server: AOLserver/4.0.10
Content-Type: text/plain; charset=iso-8859-1
Content-Length: 8
Connection: close

RedirectConnection closed by foreign host.

And if I request test2.tcl directly, I get

GET /test2.tcl HTTP/1.0

HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/html
Set-Cookie: ad_session_id=80111202%2c0+%7b453+1140224589
+962CB2C08C8F3888B4A1FF91770F02814E70BB45%7d; Path=/; Max- Age=1200
Server: AOLserver/4.0

ns_conn headers - size = 0<br>
<p>
ad_conn headers - size = 0<br>
<p>
ns_conn outputheaders - size = 2<br>
key = Set-Cookie, value = ad_session_id=80111202%2c0+%7b453
+1140224589
+962CB2C08C8F3888B4A1FF91770F02814E70BB45%7d; Path=/; Max-
Age=1200<br>
key = Server, value = AOLserver/4.0<br>
<p>
ad_conn outputheaders - size = 2<br>
key = Set-Cookie, value = ad_session_id=80111202%2c0+%7b453
+1140224589
+962CB2C08C8F3888B4A1FF91770F02814E70BB45%7d; Path=/; Max-
Age=1200<br>
key = Server, value = AOLserver/4.0<br>
Connection closed by foreign host.

So Set-Cookie is there.

However, if I request test.tcl in the browser, I get redirected to test2.tcl which prints out the output of ad/ns_conn headers and ad/
ns_conn outputheaders, where there is nary a Set-Cookie in sight.
Somehow it's getting lost along the way.

I'm perplexed.

janine

On Feb 17, 2006, at 3:45 PM, Tom Jackson wrote:
Janine,

So the command sequence I use goes like this:

$ telnet rmadilo.com 80
Trying 216.211.130.179...
Connected to rmadilo.com.
Escape character is '^]'.
GET /mypage HTTP/1.0
Host: rmadilo.com

HTTP/1.0 200 OK
Set-Cookie: SessionID =
"9A7EDDAAACCD226251DFC34240FA7A320FA7FE5C" ; Max-Age =
911003711 ; Path=/
Set-Cookie2: SessionID =
"9A7EDDAAACCD226251DFC34240FA7A320FA7FE5C" ; Max-Age
= 911003711 ; Path=/ ; Version = 1
Last-Modified: Mon, 09 May 2005 23:27:28 GMT
MIME-Version: 1.0
Date: Sat, 18 Feb 2006 00:24:49 GMT
Server: AOLserver/4.0.10
Content-Type: text/html; charset=iso-8859-1
Content-Length: 29
Connection: close

<a href="/files/">Files</a>


It is only necessary to use the Host: header if you use virtual
hosting.

tom jackson

On Friday 17 February 2006 15:12, Janine Sisk wrote:
If I telnet in and do "GET /" I just get the HTML for the page,
like
you would expect:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd";>
<html>
<head>

and so forth. If I request the page that does the redirect I get

GET test.tcl
RedirectConnection closed by foreign host.

However if I request test.tcl in the browser I do get properly
redirected to test2.tcl.  I am not very well versed in telnet
commands, so if there's something else I can do to get more info,
please let me know.

Yes, I have printed out the contents of outputheaders and the
Set-
Cookie is there, but it doesn't make it through the redirect.

janine

On Feb 17, 2006, at 2:48 PM, Tom Jackson wrote:
Janine,

If you telnet into the page, what do you get sent back?

I'm not sure where in here you add the Set-Cookie header? Do you
know that it
is in the output headers at the time you grab a copy of the set?

tom jackson

On Friday 17 February 2006 14:10, Janine Sisk wrote:
This should be simple, but it's turning out not to be.

First I used this code, which I got from a post at openacs.org
(and
the poster got it from the AOLserver docs for ns_respond):

set headers [ns_set new myheaders]
ns_set put $headers location $url
ns_respond -status $return_code -type text/plain  -string
Redirect -
headers $headers

This worked as far as the redirect and status code are
concerned, but
cookies were no longer functioning.

I noticed that ad_set_cookie (an openacs proc) adds a key
called
Set-
Cookie to the "ns_conn outputheaders" set, so I tried this,
hoping to
capture all possible relevant values:

set headers [ad_conn headers]
set outputheaders [ad_conn outputheaders]
set allheaders [ns_set merge $headers $outputheaders]
ns_set idelkey $allheaders location
ns_set put $allheaders location $url
ns_respond -status $return_code -type text/plain -string
Redirect -
headers $allheaders

No improvement;  cookies still don't work.  BTW, I tried it
with
both
ns_conn and ad_conn but they both give the exact same
output, so
same
end result.

Any suggestions on what I might be doing wrong here?

I know that the best way to fix this would be to create an
ns_returnmoved function in AOLserver, but I was trying to avoid
having any of our clients using a customized version.

Thanks for any suggestions,

janine


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF
AOLSERVER"
in the
email message. You can leave the Subject: field of your email
blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave
the
Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER"
in the
email message. You can leave the Subject: field of your email
blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave
the
Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER"
in the
email message. You can leave the Subject: field of your email
blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER"
in the
email message. You can leave the Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the
email message. You can leave the Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to