201505 - Multiple sessions get incorrecte data when opened from the same virtual directory

Status: VERIFIED DUPLICATE of bug 117222

(Core :: Networking: Cookies, defect)

Description

[Josh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

I have a Multithreaded Visual Fox Pro 8 COM object (dll) that connects to a
Microsoft SQL Server 2000 database and pulls customer information and stores it
in local variables on the object.  I have an ASP page that creates an instance
of the object (Set Session("tk") = CreateObject("Object.class")) and can then
access various information about individual customers.  I then load two
instances of Mozilla from the same virutal directory.  In the first one I load
customer A, and in the second customer B.  Now that the information is loaded
into the COM objects, my pages can display the individual information.  The
instance of Mozilla that was loaded last will show the correct information, i.e.
customer B; however the instance that was loaded first also shows customer B
information.  At first I thought this was a problem with VFP not truely being
multithreaded or IIS not allowing the object to be multithreaded.  I tested the
procedure in Microsoft Internet Explorer 6.02 and it works as intended.  I was
intially using Mozilla 1.2.1 with the same incorrect results as Moziila 1.3

Reproducible: Always

Steps to Reproduce:
1.  Have a COM object that can access multiple records from a dB and store
values from a record in its properties (My COM object was written and compiled
in VFP 8 as a multithreaded dll and connects to a Microsoft SQL Server 2000 dB)
2.  Create ASP page to create a Session variable that is assigned to the COM
object (i.e. Set Session("myVar") = CreateObject("Object.class"))
3.  Allow the ASP page to access the COM object and load specific records into
the COM objects properties (i.e. Session("myVar").LoadCustomer("A"))
4.  Open two (or more) browsers, connect to the same ASP pages and load two (or
more) individual records.
5.  Display the loaded information from the COM object on the ASP page in one
broswer (i.e. in ASP <%=Session("myVar").CustomerName%>)
6.  Display the loaded information from the COM object in the other brower(s)
Actual Results:  
The information that was loaded last gets displayed for each instance of the
browers.  It acts like the object is not multithreaded, unless you create the
object in two seperate virtual directories, then it preforms correctly

Expected Results:  
Each browser should display the information that was loaded for it's specific
session.

Since I have ruled this out to not being a problem with the dll being
multithreaded or IIS, since this example works fine in IE 6.02, I am assuming it
is most likley in how Mozilla is creating/referencing the session.  I have not
tested this without the COM object since that is what I am currently developing.
 Mozilla does not have this problem if I put the pages in two different Virtual
directories and point them at the same dB.  Also, if you happen to make a
multithreaded dll in VFP becareful with the global variables they are NOT
multithreaded, this is a bug in VFP.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I then load two instances of Mozilla from the same virutal directory.

Two instances?  Or two windows of the same instance?  Are they using different
profiles?

Comment 2

[Josh]

Two windows both are using the same profile.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Then they're the same Mozilla instance, not different instances. In particular,
they are sharing cache and cookies (don't know whether this affects your situation)

Comment 4

[Josh]

Do they also share the same Session variables, since Session variables are
considered a type of cookie?  If so then this is what is causing my problem.

Comment 5

[Boris Zbarsky [:bzbarsky]]

If they're a cookie, then yes they would be shared.

Comment 6

[Josh]

Okay,

  I did some more testing and here is what I found:
The following code will always display the same Session ID for Mozilla, and
Opera, however; in IE if you open two windows by using the icon you will receive
different Session ID's, but if you use the Menu File->New->Window then it will
use the same session ID.

<HTML>
	<BODY>
		<%=Session.SessionID%>
	</BODY>
</HTML>

Since session variables are considered a type of cookie, and since I can't find
any specifics on the scope of a session variable from microsoft (they probably
hide it in a closet some where when they designed it.  :) ), I am assuming that
Mozilla and Opera are doing the correct process.

I also found a microsoft KB article that refers to an option that no longer
exists, and pretains to the brower's session and whether or not to create new
sessions:

   http://support.microsoft.com/default.aspx?scid=kb;en-us;Q240928

I would like to thank you for your quick responses, and help with finding out
what was going on.

Thanks,
Josh

Comment 7

[Josh]

It looks as if it is another undocumented microsoft "feature".

Comment 8

[Josh Birnbaum]

reopen, there is an open bug about this

Comment 9

[Josh Birnbaum]

*** This bug has been marked as a duplicate of 117222 ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

> in IE if you open two windows by using the icon

Then you get two separate IE processes.

Comment 11

[Josh]

Correct.

And until I see a standard for when a new Session ID should and should not be
given to a web browser, I can not see this as being a bug.  I would see it more
as a feature request.

Comment 12

[benc]

do we know for sure the session id is being sent by cookie and not http?

Comment 13

[Josh]

Since I have never gotten that deep into the code of an http server, I do not
know for sure of what sets the Session ID.  However, I will make an educated
guess based on all the research that I have done in the past about web sessions.
 Since one can code a web page to request a specific Session ID, and if that
session id exists the server will allow it to be used (which I truthfully think
is a security hole on the server side).  I believe that the server itself
creates the session id whenever a connection is made as long as there is not a
request to use an existing session id.  However, session variables are
considered cookies, and are stored on the end users harddrive until the session
ends.

Comment 14

[benc]

VERIFIED/dupe:

you should be able to look in your cookie manager and see some kind of SID or
session cookie.

Some servers track sessions via IP, but there are reasons that is in effective,
so I'm 99% sure your session was cookie based, now that I think about it more.

As for your last comment...

well, that is a server problem, nothing you can do. I was having lunch w/ a
server-side buddy (talking about this exact issue), and she said that basically
nobody on the server side trusts the sesion-id in cookie anymore w/o some extra
validation.

I think the general idea is that the lack of a session-id makes it pretty clear
you gotta assign one. having a sesion-id does not automatically authenticate
your transaction.