patrick,
there are a couple gotchas along the way; i'll call out as many as i can
think of, and that might get you a good way towards where you want to be.
1. what you describe is exactly what we're doing, in a filter, to ensure a
sessionId on every request.
2. "setting a cookie" really means "adding a set-cookie header to the
outputheaders, the value of which is "name=value; [path|expires|domain=...]"
this odesn't get sent to the browser until a response is made- so it won't
be in the request headers until the browser's next request.
2a.a. if the page where the cookie is set and the redirected location are in
different directory paths, you'll want to set the path attribute to
something standard- we use "/", since the only cookie we're using is
sesionId- things other than that are set using an nsv which is looked up
based upon the sessionId cookie. also, if you want to store the cookie on
the users' disks, you'll have to set the expires to something in the future.
an unset expires means "only in the browser session" which really means
"until the user closes the browser". a favorite resource of mine is:
http://home.netscape.com/newsref/std/cookie_spec.html
2a. this assumes that you include the aforementioned outputheaders in the
request. note that ns_returnredirect doesn't allow for a -headers
arguement. we instead use a wrapper around ns_respond, which isn't as bad
as it first seems.
2b. there was a bug a while back i noted but never took the time to
duplicate, about ns_conn outputheaders not working. it might be part of
your problem. do a search of the archives for the string "TCL_OUTHDRS" or
"ns_conn outputheaders does not work" and you'll probably hit the bug i'm
talking about.
i think in general you'll want to switch to using ns_respond and setting
your own outputheaders, but ns_returnredirect should pass along the correct
headers- i.e. including the ones you've set.
folks, is this last assumption correct?
-----Original Message-----
From: Patrick Spence [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 1:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] Form Posting
Part of what I am trying to work around is cookies not setting on a
redirect... as one part of what I am doing is where I am authenticating the
user and setting a sessionid cookie as part of my user tracking and
security... if I use a standard redirect the cookie vapors... right now I
am following the path of setting a url with the username as a variable (part
of what I would like to pass as a form post to keep hidden), and redirecting
the user to a new page that pulls that username from the form data and uses
it to build part of the session cookie.. that page then uses a meta-refresh
to redirect to the users page.
The users page (and all pages past that point) check to see if a
sessioncookie is set and that its coming from a valid referrer.. if either
condition is not true it redirects them back out to the login page.
A bit of a kludge fix, but without the capacity to set a cookie then do a
ns_returnredirect (which I have been assured by my code-guru and my brief
testing doesn't work) this is what I came up with to track things..
--
Patrick Spence, Network Administrator
Information System Dept.
2401 South 24th Street, Phoenix, AZ 85034
[EMAIL PROTECTED] - http://www.vitamist.com
----- Original Message -----
From: "Jerry Asher" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 11:11 AM
Subject: Re: [AOLSERVER] Form Posting
> At 11:02 AM 8/23/01, you wrote:
> >I want to be able to redirect the user to another url on my site, and
send
> >information to the tcl script residing at that url (register_proc) using
> >form data.. without the URL including the content of what I am sending..
so
> >I can then operate on that sent data without it being painfully clear
what
> >that data is to the average joe user... I don't want to use a database
and
> >store temporary data and refer back to that... it would make it more
complex
> >and add to the database usage in areas that don't need more of it...
>
> Try Rob's internal redirect utility, which as he says provides a tcl
> wrapper for ns_connredirect. The effect is basically a "goto" or
> "overlay". One moment you are running one script, then you internally
> redirect, and you start running your other script. What's most fun is
that
> all your tcl variables are still there with the same values. So you need
> not post at all.
>
> I've used this for exactly the purpose you've given.
>
> rob's utilities: http://www.dqd.com/~mayoff/aolserver/#dqd_utils
> ns_connredirect doc: http://www.aolserver.com/docs/cdev/c-ch90.htm#576649
>
>
> Jerry
> =====================================================
> Jerry Asher [EMAIL PROTECTED]
> 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
> Berkeley, CA 94709 Fax: (877) 311-8688
