Dan,
> if it is happening you will see billing information for martinez before it
> boots you out and then you will see a different user reference number in the
> URL address. So far it seems to always be. B8A436555E2F4B073F577E02

We have looked at the variable store dump file and the
B8A436555E2F4B073F577E02 which you stated always appears user reference does
not exist.  There are 12 active user sessions and 2 application session.
They are:

User 1: [EMAIL PROTECTED] (total data 513 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 926
There are 4 variables found for this user

User 2: [EMAIL PROTECTED] (total data 21 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 0
Time left (sec): 0
There are 11 variables found for this user

User 3: [EMAIL PROTECTED] (total data 680 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 1715
There are 23 variables found for this user

User 4: [EMAIL PROTECTED] (total data 518 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 1229
There are 8 variables found for this user

User 5: [EMAIL PROTECTED] (total data 594 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 1389
There are 14 variables found for this user

User 6: [EMAIL PROTECTED] (total data 617 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 1769
There are 17 variables found for this user

User 7: [EMAIL PROTECTED] (total data 37 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 0
Time left (sec): 0
There are 17 variables found for this user

User 8: [EMAIL PROTECTED] (total data 8894 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 1311
There are 12 variables found for this user

User 9: [EMAIL PROTECTED] (total data 5 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 138
There are 2 variables found for this user

User 10: [EMAIL PROTECTED] (total data 513 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 167
There are 8 variables found for this user

User 11: [EMAIL PROTECTED] (total data 8930 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 755
There are 21 variables found for this user

User 12: [EMAIL PROTECTED] (total data 513 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 0
There are 4 variables found for this user

User 13: [EMAIL PROTECTED] (total data 8929 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 907
There are 20 variables found for this user

User 14: [EMAIL PROTECTED] (total data 519 bytes)
Dump time: Thu Sep 04 06:45:31 EST 2003
Expiry time (sec): 1800
Time left (sec): 0
There are 8 variables found for this user

In regards to the same user reference argument reoccuring, it is highly
improbable that the server would create the same user reference argument
time and time again within an acceptable period of time as the user
reference is based on 2 random numbers and the current time.  I am curious
as to how the same user references keeps appearing over and over again.

We will need some more information on how you are passing the http session
off to the https request and back again to be able to work out what is
happening.

Phil

On 5/9/03 10:23 AM, "Dan Stein" <[EMAIL PROTECTED]> wrote:

> Nope none of that. No hack it happens to a bunch of us.
> 
> It is the variable cache dump file if that has the number in there.
> 
> I sent the file to with and called them this evening to ask that they look
> at the binary right away and see if they find that number in the file. If
> they do that pretty much proves it.
> 
> Everything else has been tried.
> 
> on 9/4/03 19:48, Ben Johansen at [EMAIL PROTECTED] wrote:
> 
>> Use the date of the log entries and then check for TAFs modified on that
>> date. Check to see if user reference is accidentally entered as hard
>> coded.
>> 
>> Turn up logging to highest level and view the full request that seems to
>> be locking you up. Since it is an old userreference it might be a hack
>> attempt
>> 
>> Ben Johansen - http://www.pcforge.com
>> Authorized Witango Reseller http://www.pcforge.com/WitangoGoodies.htm
>> Authorized MDaemon Mail Server Reseller
>> http://www.pcforge.com/AltN.htm
>> 
>> 
>> -----Original Message-----
>> From: Dan Stein [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, September 04, 2003 4:13 PM
>> To: [EMAIL PROTECTED]
>> Subject: Witango-Talk: Critical Issue
>> 
>> I have a recent issue with a site
>> 
>> Witango server V5.062 windows 200 server.
>> 
>> Intermittently the session is lost ( I boot them out if the user
>> variable we
>> need is not present.
>> 
>> Rest assured we pass userreferance arguments everywhere and I mean
>> everywhere. 
>> 
>> We also pass a random number between 100,000 and 1,000,000,000
>> 
>> We also do everything you can with the headers and IIS to force new
>> pages.
>> 
>> Prior to going to V5.062 it seemed the only time session was lost was
>> when
>> we might expect it. Improper use of back buttons and refreshes after
>> logout.
>> 
>> But in the last two weeks we are seeing loss of session when moving
>> between
>> the HTTP site and HTTPS.
>> 
>> The directory does not change just the SSL
>> 
>> It is intermittent. When it happens it seems to last about 2 hours and
>> effect most but not all people.
>> 
>> It resolves by itself.
>> 
>> I even created a small simple taf that just tests it by printing my name
>> as
>> a user variable to the page.
>> 
>> When it is happening the test file confirms the loss of session. When it
>> is
>> not all works fine.
>> 
>> When you are booted out the same user reference number comes up no
>> matter
>> who it happens to and it is a number that was fist used about 2 weeks
>> ago
>> from what I see in the logs.
>> 
>> So... I stop the service and deleted the file in the Witango Server
>> variable
>> cache directory and then restarted the server.
>> 
>> I submitted the file with my bug report.
>> 
>> Does this sound like what other people were seeing on the list?
>> 
>> Does removing the file fix the problem?
>> 
>> Does it re occur?
>> 
>> Has anyone heard back from customer support?
>> 
>> This is my biggest client so this is a serious major problem.

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

Reply via email to