OK I think you have made this pretty clear and what I have done is removed
the session cookie expire for now and added a purge of user variables and
cookie variables and request variables to the sd.tml page so if they get
there somehow with variables it will clear them and then they will get built
anew with the login.
I'll watch 5the logs and email and see if this works.
Dan
on 12/4/03 16:41, Scott Cadillac at [EMAIL PROTECTED] wrote:
> 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
>
--
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
