Hi Dan,
> Maybe there is no issue.
>
> So if I understand correctly.
>
> I don't need to purge the session cookie in this instance when they log
> out.
I can't think of a single issue where it would be necessary to deliberately purge the
Witango_UserReference session-cookie.
Session-cookies, of which Witango_UserReference is one, by definition are
automatically
purged by the browser as soon as you close your browser windows. This is a browser
thing -
nothing to do with Witango.
>
> It user variables are gone so that user reference will be left with the
> session cookie and reassigned new variables.
>
> Correct?
Correct.
> In the case where they do not log out and they use a bookmark to load
> the
> enter page again will the fact that I expire the session cookie on that
> page
> take care of making sure a new userreference is assigned to hold new
> user
> variables?
Non-issue. Don't try to deliberately expire the Witango_UserReference session-cookie.
The browser does this for you automatically, therefore a new key will be issued by the
Witango Server when they come back to the page, and thus the User has to logon again.
----
One factor that may be complicating the issue, is whether or not you're using
<@USERREFERENCEARGUMENT> with your links. If so, then bookmarking is your enemy.
Again, another reason "not" to have <@USERREFERENCEARGUMENT> in your code.
> From what you say it sounds like what I am seeing might be normal
> behavior
> and acceptable.
Yes.
But again, make sure you trap the User on the logon form - if they have variables,
then just
show them a Logout button. Only when required variables are absent do you show them
the
Logon form.
Don't worry about the session-cookie, Witango takes care of this for you behind the
scenes.
----
Note: the only exception to the above, is when you are assigning custom HTTP Headers
via
<@ASSIGN request$httpHeader VALUE="...">, then some special Metatags are required with
this
assignment.
> I am just wondering two things.
>
> If this is at the enter page
>
> <@ASSIGN cookie$witango_userreference <@userreference>
> expires="Saturday,
> 01-Nov-2003 01:00:00 GMT ">
>
> Why does the session cookie get reused?
Don't do that.
The fact that you assign an "expires" attribute (by difinition), means that it is no
longer
a session-cookie - regardless of the value.
All you are doing here is introducing unpredictable behavior, because now the
Witango_UserReference cookie key value is stored on the harddrive and potentially
accessiable.
>
> If I put this at the logout page
> <@ASSIGN cookie$witango_userreference <@userreference>
> expires="Saturday,
> 01-Nov-2003 01:00:00 GMT ">
>
> Will that keep the cookie from being reused?
Don't do this either. (see above)
> And finally if this is my enter page a .tml file
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
>
> <TITLE></TITLE>
> </HEAD>
> <BODY>
> <@ASSIGN cookie$witango_userreference <@userreference>
> expires="Saturday,
> 01-Nov-2003 01:00:00 GMT ">
> <@COMMENT><META HTTP-EQUIV="REFRESH" CONTENT="0;
> URL=login.taf?nc=<@RANDOM
> Low='1000' HIGH='2000000' ENCODING=URL>"></@COMMENT>
> <CENTER><SCRIPT language="javascript">document.write('<a
> href="login.taf?'
> + Math.round(Math.random()*1000000000) + '"><IMG
> SRC="<@CGI><@APPFILEPATH>Graphics/AnimationKnob.gif " BORDER=0
> ALIGN=CENTER
> ALT="Enter the Site"></a>')</SCRIPT>
> <CENTER></BODY>
> </HTML>
>
>
>
> Should I add a <@Purge> to this page also just to do any housekeeping
> from
> people who did not log out?
That is one way to do it, but I prefer my earlier suggestion. Where, if User Scope
Variables
are present - then just show them the Logout button.
----
In summary, unless you have a very very specific purpose, don't try and re-assign or
purge
the Witango_UserReference session-cookie.
Typical application coding does not require you to do anything special to manage
sessions or
User Scope variables - other than to <@ASSIGN> them, and check for them <@VAR> at
certain
key points in your code, and to <@PURGE> them when the user logs out.
Witango takes care of the rest for you.
Hope this helps......
> 12/4/03 15:54, Scott Cadillac at [EMAIL PROTECTED] wrote:
>
> > Hi Dan,
> >
> > Like I described, as long as you <@PURGE SCOPE=USER>, then the
> > <@USERREFERENCE> key (session-
> > cookie or argument) is reusable by the same browser instance.
> >
> > According to your log, the person started a new clean session - so I
> guess I'm
> > confused to
> > what the issue is.
> >
> > Can you give us more detail?
> >
> >
> >
> > -----Original Message-----
> > From: Dan Stein <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Date: Thu, 04 Dec 2003 15:45:23 -0500
> > Subject: Re: Witango-Talk: Session issues
> >
> >> Well it sounds all fine in theory but in practice I can document is
> not
> >> working.
> >>
> >> When they log out I do purge the user scope and when they log back
> in
> >> from
> >> there it takes them to a page the makes uses JavaScript to generate
> a
> >> random
> >> number for the link to login, does not pace a userreferance with the
> >> link,
> >> and sets a witango session cookie expiration in the past so it
> should
> >> force
> >> a clean slate.
> >>
> >> They then click enter which passes them to the login taf and passes
> a
> >> nc
> >> value generated by the JavaScript.
> >>
> >> The form does not pass a userreferance when the log in.
> >>
> >> This according to Ian is pretty much fool proof.
> >>
> >> IT claims it is not caching this site ( I have my doubts) so maybe
> that
> >> has
> >> something to do with why I see this session issue.
> >>
> >> But I can document what happens because I get an email with a dump
> of
> >> all
> >> the variables with every log in and log out so as you see below for
> >> example
> >> she logs in as John I then logs out then logs in and Carol but the
> user
> >> reference is the same.
> >>
> >>
> >>
> >> Sandee does this.
> >>
> >> Logs in
> >> John Iannacone logged in at 12/04/2003/13:13:55
> >> D28D094187265EC83FCF7958
> >> _UserReference=D28D094187265EC83FCF7958
> >>
> >>
> >> Then logs this person out
> >>
> >> John Iannacone logged out at 12/04/2003/14:34:31
> >> D28D094187265EC83FCF7958
> >> _UserReference=D28D094187265EC83FCF7958
> >> D28D094187265EC83FCF7958
> >> _UserReference=D28D094187265EC83FCF7958
> >>
> >>
> >>
> >> Then logs in as Carol
> >>
> >> Carole Jones logged in at 12/04/2003/14:34:46
> >> D28D094187265EC83FCF7958
> >> _UserReference=D28D094187265EC83FCF7958
> >>
> >>
> >> Woops the numbers is the same.
> >>
> >> on 12/4/03 15:18, Scott Cadillac at [EMAIL PROTECTED] wrote:
> >>
> >>> Hi Dan,
> >>>
> >>> In theory there is nothing wrong with what this person is doing.
> >>>
> >>> The key to the issue is how deligently you manage the session(s)
> with
> >> your
> >>> code.
> >>>
> >>> For example, if someone has succesfully logged in, then clicks a
> link
> >> to go to
> >>> the logon
> >>> page "again" - don't show them the Logon form if they already have
> >> their
> >>> specific "allowed"
> >>> User Scope variables, just show them a Logout button.
> >>>
> >>> This way you force them to close their "session" before starting a
> >> new one.
> >>>
> >>> As long as you do <@PURGE SCOPE=USER> when they logout, then it
> >> doesn't matter
> >>> that they
> >>> start a new "session" with a previously used <@USERREFERENCE> key.
> >>>
> >>> ---
> >>> Another scenario:
> >>>
> >>> If a user has an active session, then starts a new browser instance
> >> from
> >>> scratch (like from
> >>> the computer's Start menu) - there is also nothing wrong with this
> >> because the
> >>> new browser
> >>> isntance will not have any "session-cookies" (previously used or
> >> otherwise).
> >>>
> >>> A single computer can then run two independent sessions (with
> >> different
> >>> <@USERREFERENCE>
> >>> keys) this way, and the two should not interfer with each other.
> From
> >> a User
> >>> point of view
> >>> it can be confusing, but I test application like this often at it
> is
> >> reliable
> >>> - at least
> >>> with MS Internet Explorer on Windows.
> >>>
> >>> The one caveat: is when posting to windows with specificaly target
> >> "names" -
> >>> at this point,
> >>> then a page that belongs to one session can potentially crossover
> and
> >> inherit
> >>> a window (and
> >>> it's associated session) from the other user.
> >>>
> >>> ---
> >>> In summary, a User who wants to open more than one session (of
> >> themselves or
> >>> for other
> >>> people), they should start a new browser instance to do so. If they
> >> don't, you
> >>> just need to
> >>> trap them at the logon form (as described earlier) with your code.
> >>>
> >>> Hope this helps. Cheers......
> >>>
> >>> Scott Cadillac,
> >>> Witango.org - http://witango.org
> >>> 403-281-6090 - [EMAIL PROTECTED]
> >>> --
> >>> Information for the Witango Developer Community
> >>> ---------------------
> >>>
> >>> XML-Extranet - http://xmlx.ca
> >>> 403-281-6090 - [EMAIL PROTECTED]
> >>> --
> >>> Well-formed Development (for hire)
> >>> ---------------------
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Dan Stein <[EMAIL PROTECTED]>
> >>> To: <[EMAIL PROTECTED]>
> >>> Cc: Robert Shubert <[EMAIL PROTECTED]>
> >>> Date: Thu, 04 Dec 2003 14:48:18 -0500
> >>> Subject: Witango-Talk: Session issues
> >>>
> >>>> OK at least I have a reason behind the scrambled numbers today.
> >>>>
> >>>> There is one admin user who finds it better to log in as the
> >> specific
> >>>> staff
> >>>> person from here computer than sometimes she remembers to log out
> >>>> sometimes
> >>>> she does not but just logs in again as a new user. So we have
> >> multiple
> >>>> sessions starting from the same machine.
> >>>>
> >>>> Despite what we are doing with the tafs and cache I expect her
> >> session
> >>>> cookie is still alive and so when she logs back in again she will
> >>>> sometimes
> >>>> get the same userreferance number.
> >>>>
> >>>> I have asked her to actually quit IE before logging in as another
> >>>> person but
> >>>> I think I will put that assign action to expire the session cookie
> >> on
> >>>> the
> >>>> log out page also to see if that helps.
> >>>>
> >>>> Any suggestions besides that?
> >>>>
> >>>>
> >>>> --
> >>>> Dan Stein
> >>>> Digital Software Solutions
> >>>> 799 Evergreen Circle
> >>>> Telford PA 18969
> >>>> Land: 215-799-0192
> >>>> Mobile: 610-256-2843
> >>>> Fax 413-410-9682
> >>>> FMP, WiTango, EDI,SQL 2000
> >>>> [EMAIL PROTECTED]
> >>>> www.dss-db.com
> >>>>
> >>>>
> >>>> "When you are born, you cry and those who love you rejoice.
> And
> >> if
> >>>> you
> >>>> live your life as you should, when you die, you rejoice and those
> >> who
> >>>> love you cry."
> >>>>
> >>>>
> >>
> _______________________________________________________________________
> >>>> _
> >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
> >>>
> >>>
> >>
> _______________________________________________________________________
> >> _
> >>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
> >>>
> >>
> >> --
> >> Dan Stein
> >> Digital Software Solutions
> >> 799 Evergreen Circle
> >> Telford PA 18969
> >> Land: 215-799-0192
> >> Mobile: 610-256-2843
> >> Fax 413-410-9682
> >> FMP, WiTango, EDI,SQL 2000
> >> [EMAIL PROTECTED]
> >> www.dss-db.com
> >>
> >>
> >> "When you are born, you cry and those who love you rejoice. And
> if
> >> you
> >> live your life as you should, when you die, you rejoice and those
> who
> >> love you cry."
> >>
> >>
> _______________________________________________________________________
> >> _
> >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
> >
> >
> _______________________________________________________________________
> _
> > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
> >
>
> --
> Dan Stein
> Digital Software Solutions
> 799 Evergreen Circle
> Telford PA 18969
> Land: 215-799-0192
> Mobile: 610-256-2843
> Fax 413-410-9682
> FMP, WiTango, EDI,SQL 2000
> [EMAIL PROTECTED]
> www.dss-db.com
>
>
> "When you are born, you cry and those who love you rejoice. And if
> you
> live your life as you should, when you die, you rejoice and those who
> love you cry."
>
> _______________________________________________________________________
> _
> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
