Firefox, Safari, Chrome dropping PHP session after action on iframe...but not IE

Jason C. Levine
Jason C. Levine used Ask the Experts™
on
Hi folks,

I have an odd problem.  We are using sessions to hold login data and pass it around as needed.  One app we are using is FileChucker (http://encodable.com/filechucker/) which uses an iframe to upload one or more files.  

We are noticing that sometimes (not every time), Firefox, Chrome, and Safari will lose the initial session after uploading a file.  IE never loses its session.  If a user loses their session and re-logs in and uploads a new file, they do not lose the session.

Has anyone else run into this behavior?  Any ideas on what we should be looking for in the scripts?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Altin BardhiSoftware Engineer

Commented:
Normally IE gets the whole file paths (when we use JavaScript for example) while the other browsers only the file name (file security reasons). It can happen that the user could upload an image with spaces on file name. If this happens, you the image may be uploaded but you may not be able to get the expected results on other browsers than IE.

I hope this gives you some clues.

Regards
Jason C. LevineDon't talk to me.

Author

Commented:
Hi albacom,

The files are being uploaded just fine and we are testing with "normal" names (no spaces or punctuation aside from the .extension).

 
Altin BardhiSoftware Engineer

Commented:
It looks like the session is being destroyed after the user uploads a file. Are you setting a lot of cookies? Some browsers don't hold more than 20 cookies. If you are passing complex data then it is best to use the database to hold the data. You can create random tables and destroy them after retrieving the data to the next page.
Exploring ASP.NET Core: Fundamentals

Learn to build web apps and services, IoT apps, and mobile backends by covering the fundamentals of ASP.NET Core and  exploring the core foundations for app libraries.

Top Expert 2005
Commented:
My best guess:  PHP.NET-->"The session cache limiter defines which cache control HTTP headers are sent to the client."

"I'm assuming headers are being sent, since you are doing a file upload."

PHP.NET-->"The Expire header sent to the client may cause confusion for some browsers, including Mozilla. You can avoid this problem by using "private_no_expire mode."

The confuse Mozilla part peaked my interest.

PHP.NET-->"The cache limiter is reset to the default value stored in session.cache_limiter at request start up time. Thus, you need to call session_cache_limiter() for every request (and before session_start() is called)."

So, in the page in the IFrame, try session_cache_limiter('private_no_expire mode');

At the very least you are telling the browser not to drop the session. Whether or not the browser pays attention is anyone's guess as they don't always respond to every header command.

Simple enough to try, though.

Regards,
Rod
Altin BardhiSoftware Engineer

Commented:
Also if you are setting the session from the IFRAME, you can try to set a cookie instead. Make sure it is accesible from where you call it. (path='/') After setting the cookie you can always asign it back to the session and destroy the cookie. You can also try to use obb_start(); just after session_start();
Jason C. LevineDon't talk to me.

Author

Commented:
Rod, thank you.  Passing that onto the devs and will make them try it.

albacom,

In PHP, setting a session sets a cookie anyway.  But we'll give it a whirl.
Altin BardhiSoftware Engineer

Commented:
I only got that idea as sessions could expire if you close the page but cookies not unless you destroy them before their expiry time.
Top Expert 2005
Commented:
>In PHP, setting a session sets a cookie anyway.  But we'll give it a whirl.

But a header problem could cause the cookie to go bye bye.  They are, after all, created and killed with headers.

Tamper Data on Firefox should tell you what is going on.
Altin BardhiSoftware Engineer
Commented:
If you use ob_start() on the header.html then you could send a cookie even if there was an output prior to setting a cookie.
Jason C. LevineDon't talk to me.

Author

Commented:
Hey guys,

Sorry for the radio silence.  We're still running with the suggestions and trying to get a consistently repeatable error/solution.
Don't talk to me.
Commented:
Hi guys,

So the problem turned out to be something very simple...so simple that we all missed it.

Filechucker has a hardcoded URL (no way to just use a path) at one step and if the user started the process at http://domain.com/, s/he lost the session at that step (going to http://www.domain.com/).

If the user started at http://www.domain.com/, they never lost the session.

Sessions are URL sensitive.  Who knew?

The weird thing about all of this is the IE never cared what domain the user started from.  But it mattered to Firefox and Safari.

So we changed the server to redirect all http://domain.com to http://www.domain.com and the problem disappeared.

Thanks to you both.  You got us thinking about the problem in the right way.  Points are yours, but I'll be accepting this post as the solution.
Top Expert 2005

Commented:
>Sessions are URL sensitive.  Who knew?

I knew that but like you said, so simple it would have never occurred to me.
Jason C. LevineDon't talk to me.

Author

Commented:
>> I knew that

So why does IE not care about the URL?
Altin BardhiSoftware Engineer

Commented:
One of my suggestions was:

->Make sure it is accesible from where you call it. (path='/')
Altin BardhiSoftware Engineer

Commented:
Sorry just read your post above. Thats fine with me.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial