Closed
Bug 219984
Opened 22 years ago
Closed 17 years ago
If I open two different websites on the same server the second one will force a session.timeout on the first one opened.
Categories
(Core :: Networking: Cookies, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: rschauer, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
On our local intranet we have two websites that are used together. One is a main
site while the other is an admin site. When you open one it will open properly
and you can browse freely throughout the site. But as soon as you open the other
website your session will timeout on the first one. It happens no matter which
site you open first and works fine in IE Version 6.0.2800.1106.xpsp2.030422-1633.
Reproducible: Always
Steps to Reproduce:
1. Open the first website and log in
2. Open the second website
3. Browse to a different page in the first website and it will log out due to a
session timeout.
Actual Results:
You are logged out due to a session.timeout. Even if you set the timeout to 20
minutes it will still log you out.
Expected Results:
Sessions should be specific to each website. You shouldn't have a global session
for all websites from a server. Otherwise you end up with only your newest
session being valid and any other sessions get reset, which ultimately will
cause a "session war" of people logging back again and taking the session lead. :~)
This doesn't actually cause Mozilla to crash, but it does get really annoying
when you need to work from two websites on the same server.
Comment 1•22 years ago
|
||
sounds like cookies
Assignee: blake → darin
Component: History: Global → Cookies
QA Contact: petersen → cookieqa
| Reporter | ||
Comment 2•22 years ago
|
||
I'm not using cookies in my site to verify any login data. I suppose it could be
if Mozilla is writing a cookie out behind the scenes, but if you're referring to
my own cookies being overwritten, then that's not the case. We don't use them
for security reasons. To me it appears to be a global.asa issue...but I could be
wrong.
Comment 3•22 years ago
|
||
for session management you can use a) cookies b) Authentification on the network
level c) session URLs
but how should you create a session managment via the browser history ?
how do you log-in into you page ? (form, Authentification popup...)
| Reporter | ||
Comment 4•22 years ago
|
||
We are using a form post which is verified by hitting our database.
Comment 5•22 years ago
|
||
if you're not setting any cookies at all, this isn't cookies and shouldn't be in
this component (don't know what the correct component is though)
Comment 6•22 years ago
|
||
*** Bug 243409 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 8•20 years ago
|
||
To confirm this bug report, we really need a testcase. The information in this
bug report is really not sufficient to help us resolve the problem. If you can
provide a testcase for our developers to use, that would be greatly appreciated.
Thanks!
| Reporter | ||
Comment 9•20 years ago
|
||
Unfortunately I cannot do this as our website is a government website and I
can't grant the security required to let you have access. I've given as much
info as I could and it appears that someone else had the same problem (if you
look through the other comments he opened a ticket with the same issue). Other
than that I don't know what else to say except that there is obviously a problem
and I would highly recommend looking into it more as the severity of the issue
is high considering what it is in regards to (that being session management and
the session crossing with other sessions).
If it's fixed or not doesn't really bother me, but it seems like a big security
issue that should be looked at. I really wish I could help more, but I can't. If
there are any further questions you have, please let me know and I will update
my browser version and try again. Otherwise, maybe try the other guy that was
having the problem and see if he can give you a test case.
Comment 10•20 years ago
|
||
I have made comments in the following bugs that I think are fundamentally related to this issue.
https://bugzilla.mozilla.org/show_bug.cgi?id=115903
https://bugzilla.mozilla.org/show_bug.cgi?id=247186
The serverside coding that I'm dealing with at present suggests to me that your serverside code is doing something similar. It is possible that you could solve your problem by having the two websites run on different servers or different instances of the server application. If you are running BEA that'll cost you a few pennies, but if you are running a freebie server, it's worth doing to (possibly) solve your problem.
Running the two apps in a single servlet container (if it's j2ee and depending on how the serverside code is authored - or perhaps even they are a single webapp!) means that they are possbily incapable of distinguishing between window instances of browsers on a single PC that are running as the same "process".
Only IE currently allows a user to choose to start a new process, and hence get a distinct server-side session.
Have a look at the other Bugs that I mentioned above and google "browser windows" "same process" and maybe "session" and you'll find a raft of server-side developers complaining about session management and multiple browser windows.
Cheers
Rob
Comment 12•17 years ago
|
||
nothing we could do without testcase
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•