Closed Bug 294623 Opened 20 years ago Closed 17 years ago

Session variables forgotten when using full URL

Categories

(Core :: Networking: Cookies, defect)

1.7 Branch
x86
All
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: osavill, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

We use an on-line transaction service call EPDQ. This requires that all contact
with it comes from a specific page. http://www.vegepa.com/checkout.php will work
but http://vegepa.com/checkout.php will not. In order to force the loading of
the correct page URL the user details entry page uses a form which explicitly
uses http://www.vegepa.com/checkout.php as its action URL. The problem is that
doing this all session variables are lost, presumably because Mozilla / FireFox
treats the URL as a new session and requests a new session ID, even though it is
the same domain. Using simply "checkout.php" as the action URL results in all
the session variables being present and correct. This behaviour does not happen
in IE - which is nice since it shows Mozilla / FireFox usage on the way up :-) !!

Reproducible: Always

Steps to Reproduce:
Setup a site with some session variable, lets say www.foobar.com
On page 1 setup a form that calls "page2.php"
On page 2 setup a form that explicitly calls "http://www.foobar.com/page3.php"
Actual Results:  
On page 1 setup a form that calls "page2.php"
   Session variables all present and correct.
On page 2 setup a form that explicitly calls "http://www.foobar.com/page3.php"
   Session variables all forgotten.

Expected Results:  
Session varaibles should be maintained throughout.

There are a few Session variable reports at the moment. I wonder how many of
them relate to this non obvious problem.

Although there are various arguments against using session variables I am
raising this as a high priority since it causes large problems for sites that
use both session variables and explicit form URLs.

I appologise in advance if this is correct behaviour and I simply need to be
doing xyz in the PHP scripts ! If this is the case could some nice kind person
tell me what this something is please ?
-> Cookies
Assignee: nobody → darin
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.7 Branch
you start talking about vegepa.com and www.vegepa.com, which are different
domains. But your steps to reproduce talks about just one domain. which is it?
If you're using host cookies, vegepa.com and www.vegepa.com are not the same. 
Best solution is to use mod_rewrite to force-append the www. prefix on urls
passed without it.  Or use domain cookies.  Either way should work just fine.
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/
The issue was not to do with www.vegepa.com or just vegepa.com. The server side 
script made a call to a second server, and this turned out to be the problem. 
Barclays EPDQ service requires that you retrieve a token from a secure server 
prior to proceeding to their secure payment pages. This referral to the second 
server is enough for Mozilla to clear session variables. IE, Opera, Konqueror 
and Safari don't appear to request the removal of session variables under these 
circumstances. It is a moot point and perhaps the spec is open to 
interpretation, but it is an issue that Mozilla / Fire Fox's behaviour differs, 
in this respect, to many other browsers out there. Moreover, I could find no 
work around !!! 
This has started happening on our Intranet. Basically a page is making a call to a different page and the session variables are scrapped. This may be a bigger issue that just calling to different server since all these particular URLs are on the same server and only differ in the page name being called.
I did experience something similiar to this before on my company's website.  It turned out the browser sometime send cookie to the server even though the one on the server is different.  So, in php.ini configuration, see if you can disable the cookie by changing the "session.use_cookies" script to go from "1" to "0".  Since I don't know your php codes and php.ini configuration so you might would have to rewrite the php codes.  Whatever happen, if you start using the pass on session identifier via links, buttons and form then you should be okay.  If this solve your problem then great.  I'm unable to create a testcase on my company's website because it is random.  So, I get hte impression that it could be a PHP issue or a browser issues.
-> reassign to default owner
Assignee: darin.moz → nobody
(In reply to comment #6)
> This has started happening on our Intranet. Basically a page is making a call
> to a different page and the session variables are scrapped. 

hmm, i'm not sure what you mean here. "session variables are scrapped"? if by variables you mean cookies, the only time we purge session cookies is on browser close. so that's definitely not happening here, the problem must be something else.
Please don't get side tracked by people writing about cookies. My original posting and comment on 4/10/2005 are accurate. The session variables are cleared, reset, initialised etc..

The problem for me is that this issue is almost 2 years old. We no longer use EPDQ and I don't have access to that particular intranet!! So I am currently unable to add any more detail.
oh, sorry, given that this is filed in the cookie component i didn't realize that the problem is likely unrelated. this is completely misfiled in that case, however given that you can't reproduce and this issue is old without any traction i'm going to close it out as incomplete.

if anyone has further information that would aid in tracking this down, please reopen and move to a different component.
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.