I figured this out as a result of this thread:
viewtopic.php?t=45685
Basically, the problem was that my session wasn't working when I used frames.
My sessions worked fine in IE, but not in FireFox. I thought the problem was my code... then I thought the problem was the frames... then I thought it was my code again.
I found that logging in twice made the session work, but I wasnt sure why. Then, if I manually entered the next page for the session, it worked... but it didnt work if I simply clicked the link to the next page.
The Solution
As it turns out, IE isnt picky about the difference between http:// and http://www but FireFox does. The reason why my session wasn't passing to the pages within my frames was because my login page was http://domain.com/login.php and the pages within the frames were http://www.domain.com/page2.php. I simply changed the links to remove the www. from them and my session works correctly.
I hope my many hours of frustration and guess/test/revise helps a few of you. I'm not sure if there's a way to set sessions in FF that work with both http://www. and http://, but I'll be sure to post it when I find it.
Cheers,
-Citizen
Session differences between FF and IE (Figured it out!!!)
Moderator: General Moderators
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
it often has to do with how the cookie for sessions is created along with how the browser does the request for framed pages. Firefox uses a different calling route than IE when loading frames. Firefox was actually acting correctly as http://www.domain.com should be considered different than domain.com.
If the domain attribute of the cookie was set to .domain.com (notice the leading dot) it will be set for the whole domain. Otherwise, it should set itself against the domain it is being created, which would cause it to only transmit the cookies to that domain and any subdomain of that.
If the domain attribute of the cookie was set to .domain.com (notice the leading dot) it will be set for the whole domain. Otherwise, it should set itself against the domain it is being created, which would cause it to only transmit the cookies to that domain and any subdomain of that.
I just received an email from someone who had different results using FF vs IE. Naively, I thought the scripts were donefeyd wrote:it often has to do with how the cookie for sessions is created along with how the browser does the request for framed pages. Firefox uses a different calling route than IE when loading frames. Firefox was actually acting correctly as http://www.domain.com should be considered different than domain.com.
If the domain attribute of the cookie was set to .domain.com (notice the leading dot) it will be set for the whole domain. Otherwise, it should set itself against the domain it is being created, which would cause it to only transmit the cookies to that domain and any subdomain of that.
Also, while reading the threads on sessions and reading the ref per your suggestion, I checked some of the settings (using phpinfo.php. I noticed session.cookie_domain had no value set. Do I need to set this value, or does php handle this. I am not explicitly setting session.cookie_domain. Is this a problem?
Is there a good example for dealing with sessions - e.g, php scripts, php ini file settings, and any other areas that are recommended for implementing session arrays?
Michael
I attempted to explicitly set the domain location in the following way:
This was placed prior to every session_start(). After doing so, I received warnings when I went to logout. the first warning occured when the script hit
The warning was "Trying to destroy uninitialized session"
Then, I received a number of warnings which, I'm guessing, occured as a result of the first warning generated output:
The warnings occured in when any script tried to execute a session_start()
The warnings were:
"Cannot send session cache limiter - headers already sent (output started.."
"Cannot send session cookie - headers already sent by (output started .."
Even after commenting out the ini_set() code, I still received the warnings. Needed to comment out the session_destroy() code to remove the warnings?
Any ideas what the original problem was - I wondered if it's because I had a session created with one domain path (prior to the change), and was wanting to destroy the session with a different domain path. Do I need to clear things out, or am I way off base. At best I have a fuzzy model of the sessions.
Any/all help would be greatly appreciated.
Michael
Code: Select all
ini_set('session.cookie_domain','./my_domain.org') ;Code: Select all
session_destroy()Then, I received a number of warnings which, I'm guessing, occured as a result of the first warning generated output:
The warnings occured in when any script tried to execute a session_start()
The warnings were:
"Cannot send session cache limiter - headers already sent (output started.."
"Cannot send session cookie - headers already sent by (output started .."
Even after commenting out the ini_set() code, I still received the warnings. Needed to comment out the session_destroy() code to remove the warnings?
Any ideas what the original problem was - I wondered if it's because I had a session created with one domain path (prior to the change), and was wanting to destroy the session with a different domain path. Do I need to clear things out, or am I way off base. At best I have a fuzzy model of the sessions.
Any/all help would be greatly appreciated.
Michael