The visitors can edit their profiles with an active password logon, etc.
With cookies broken, each visit creates a new identity unless there is an active login. There will have to be more username/password challenges at various points if visitors bypass the home page. I'm not liking this. I hope the header trick works.
BTW, MSIE (Mac, et least) allows for easy peeking at cookies and showing the content of each cookie as it is assigned. You can see exactly when a long term cookie gets turned into a session cookie.
On Friday, August 29, 2003, at 03:14 PM, Bill Conlon wrote:
Well, I'll be ....
I think this is an 062 issue
I have a login page that lets users choose whether the cookie is
permanent or session. When I first was prototyping this -- around v 054,
I couldn't get session cookies to work -- they would always expire
immediately -- until I found the work-around of using <@assign> instead
ASSIGN action. So I had advised my testers to check permanent when they
logged in.
Once I found the work-around, I alway logged in myself with session
cookies, because I always wanted to verify ny login logic. But just this
week, someone asked me whether the permanent cookies were working, and I
just assumed they were, and also assumed your problem was related to my
earlier one.
I just ran some tests with my login system -- printing out the expiration
timestamp and then checking the browser cookie status. Lo and behold ---
the cookies expire with the session!
Now this isn't critical for me, and I can just remove the checkbox so users always login with session cookies. But, I concur that this is a really serious problem.
On Friday, August 29, 2003, at 02:44 PM, Bill Conlon wrote:
1. Have you verified that you are assigning the cookies with <@ASSIGN>
and not the ASSIGN Action? This bug (ASSIGN ACTION expires cookies
immediately) perplexed me for some time.
as I've seen it, it is the same behavior no matter how assigned.
If I assign and shut down browser, then reopen browser and check
cookies, it's there, alive and well, with the right expiration date. As
soon as I hit any witango page, it then turns it into a session cookie.
2. Have you verified that the cookie expiration date set by the server
is actually in the future?
verified by looking in browser prefs
3. Have you checked cookie expiration in in the browser to make sure the expiration date is what you wanted?
yes
4. To assign cookies: <@ASSIGN NAME=name VALUE=value [SCOPE=myscope] [EXPIRES=timestamp] [PATH=path] [DOMAIN=domain] [SECURE=true|false]> <@PURGERESULTS> <@ASSIGN NAME="httpHeader" SCOPE="request" VALUE="HTTP/1.1 200<@crlf><@USERREFERENCECOOKIE><@SETCOOKIES><@crlf><@crlf>">
and I can put that between <@IFEMPTY VALUE=@@cookie$mycookie><@ELSE><@ASSIGN ... ?
ok, I seriously need to workaround this bug.
I need to refresh a cookie every time there is a hit to keep it from
disappearing at the end of a session. Can I do this in the header
file?
I look at it and it is empty, so I gather I'd have to reproduce what's
in a default header + re-send the cookie. Will this work? I know I'll
just do an @assign if I find the cookie, but what else goes in a
header? Does witango read cookies after the header is processed or
before? (if after, then this wouldn't work)
Anyone know about headers?
On Friday, August 29, 2003, at 09:21 AM, Roland Dumas wrote:
This bug is more serious than I originally thought. It actually turns
every cookie into a session cookie at every/any hit of a taf/tml -
not
just when you put a tag in that reads it, but any hit. This is a
significant problem.
it means that you have to create some sort of header that is always reading and rewriting a cookie at every hit. (Can someone help me figure out what file to edit and how?)
____________________________________________________________________ __
__
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
Bill Conlon
To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306
office: 650.327.2175 fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com
_____________________________________________________________________ __
_
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
______________________________________________________________________ __
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
Bill Conlon
To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306
office: 650.327.2175 fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
