This is a really strange problem, that appears to be somewhat intermittent (although it has started consistently occurring now - possibly due to a Windows Update?).
My code has previously worked fine in IE7, and continues to work in Firefox, Chrome, and seemingly any other browser but IE8.
I'm setting some session data and then passing the user to a payment gateway (Protx / Sage, if that makes any difference), which on return needs to reference my session data. But my session data disappears. I'm not doing anything fancy with the payment gateway display - no iframes, just a link that takes the user to the payment page, in the same browser window.
Having done some reading, I've tried adding the following to force compatibility mode in my page (as apparently this can cause IE8 to lose session data):
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
This had no effect (but then, as far as I can tell, the payment page is not forcing compatibility mode).
There seem to be quite a few people saying that iframes cause this behaviour, but again, no iframes are used.
Considering how persistent session data is in IE8 - unlike IE7, and other browsers, when a new instance of the browser is initiated, any session in another instance of the browser are accessible - I'm struggling to see where and how my session data is being lost.
I've done this kind of thing with Sage Pay before. Here is what I did, it might help:
1. Register the transaction
2. Save the current session Id to database (eg. inside the temporarily stored transaction)
3. Send the user off to sage pay to do the payment
4. Sage pay notifies you and you can load up the temp transaction
5. Pass the session id as a query string parameter for your redirect url
6. On the redirect (completion page) check if there is a session id var in the request and if there is, then call session_id($theIdYouGotFromQueryString) before calling session_start()
p.s yes i know it doesn't directly answer your question. But maybe doing it this way will help?
I had the same problem and what I tracked it down to was that if you use a page to generate the session and then once it is generated you do a header(Location:...); call IE will think it needs to generate a new session in protected mode and will drop all cookies from the previous session.
How are you storing the session - in a cookie or as a hidden variable/form field in the page (if the latter, then it probably isn't being returned from the payment gateway).
I have had a similar problem in the past with IE and sessions, but this was tracked down to the development test area having an underscore in the hostname (such as test_site.internal) which causes IE not to save cookies correctly.
You might also want to try Charles Proxy to watch the flow of data between Internet Explorer and the server(s) to see if you can see at what point the data you need stops being passed.
It sounds like a P3P problem.
See this: http://support.microsoft.com/kb/323752/en-us for IE6 and later browsers.
Related
For reasons out of my control I need to send form data to an other server and return back right away after it has been processed and alter the state of an entry in my local data base when returning.
In principle it works fine but when I return it seems my session has been terminated and I need to login again in order to reach the page I want to reach. Unfortunately, this hinders my script to actually inform my data base that the external data base has processed the data. Of course I could open up the page for public access but I want to avoid that. An other option would be to send a key with the form data and to only bypass the need for a login if the returned key is correct.
But is there a way of telling my session to only terminate after a certain time instead of when leaving the page? (Of course I want to keep the possibility to deliberately terminate the session on logout.)
I just realised that the problem seems to occur on Firefox on Windows and on Mac but not on my GNU/Linux system. There I stay logged in when leaving and returning to the web page. This is the reason why at first I didn't know that people could have this problem.
I found out that also creating a session on the external page ended the original session (at least in Firefox on Windows and on OSX). After removing the session_start() on the external page the session stays alive as intended.
It seems there can be only one active session in any given tab and creating a new session terminates the old one. (However, this termination only happens on Windows and OSX but not on Firefox ESR GNU/Linux.)
It is strange that the default setting for session cookies is to be deleted if a new session is started (if not on Firefox ESR on GNU/Linux).
What ever the true explanation is: this is the behaviour I discovered.
I'm using a PHP session variable to keep track of cart data before checkout. I've tested multiple computers and every browser on each computer, and the session variable is maintained between the cart and checkout screen. However, on the client's computers the data disappears some of the time, and a new session is started on the new page. We've never been able to replicate the problem.
Between those two pages we move to a different directory and move from http: to https:, but in testing we've been able to keep session variables even while doing that on this site. The client also has enabled third-party cookies. I've looked at solutions for similar problems but they haven't helped.
Any help would be appreciated.
I've worked on similar projects, but we were jumping domains (example.com -> secure.example.com) for checkout. The solution we used was to push the data into cache and add the cache key to the url. This way when the user landed on secure.example.com, we could get the cache key from the querystring, lookup the data in cache, and load necessary data. With this solution you never need to worry about session alignment.
I have a PHP site that works great....as long as there are no network disruptions. im having problems with users, especially on iPad's and laptops, that log in, and work within the site without submitting any data for a prolonged length of time (maybe an hour or so). They type a bunch of notes in, and when they submit they are sent to the logon screen and what they worked on for that hour is lost. I'm getting used to dirty looks...
My research as shown that maybe using cookies will help the issue. security is not a huge concern, so storing usernames and hashed password within cookies is not a big threat. but i never worked with cookies and don't know where to really begin. my objective is to have any user be able to log in, start typing in a text area, move throughout the building, maybe dropping their internet connection and picking it back up, and be able to submit the form after with no errors. any ideas? thanks in advance...
Sounds like your session is simply expiring, nothing to do with changing internet connection or Wifi AP.
Change the default PHP session expiry with PHP, or change the php.ini setting:
ini_set("session.cookie_lifetime","3600"); //an hour
The default session handler works by setting a session ID cookie on the client. With each page request, the session ID will be sent. If the session expires, the cookie will be deleted and thus the client will be shown the login screen.
That's assuming you are using the default PHP session handler (you didn't say). If that's not the problem, then it would point to a problem in your code, for example if you are trying to prevent session hijacking by comparing IP addresses (which will change as the user moves from AP to AP).
I have the following situation:
User makes request to PAGE A that displays a form (server stores cache of this page)
User submits the form to CONTROLLER that is used for form submit
CONTROLLER finds an error in user submitted data, sets a cookie ERRORS detailing such, and redirects the user back to PAGE A
PAGE A shows the original content plus the ERRORS (server stores cache of this page)
PAGE A deletes ERRORS cookie
This works, but only if I don't use cache on my system for PAGE A.
Problem is that, after deleting the cookie, browser makes a request to my server without the cookie and gets a 304 Not Modified error and, as a result, the browser still shows the page with the error, instead of without (from the original request). Server stores cache properly (for page that has an error as well as an error-free page).
Basically the server has two cached pages now: PAGE A and PAGE A WITH ERRORS.
Browser, whose last known page was PAGE A WITH ERRORS asks for server a page with conditions of PAGE A, instead of PAGE A WITH ERRORS, since cookie does not exist anymore. But it thinks that the 304 response is about the PAGE A WITH ERRORS, instead of PAGE A. I even checked the data sent by the browser, it knows that it got PAGE A WITH ERRORS with the ERRORS cookie, yet accepts 304 not modified when making requests without that cookie. It does not validate its own cache against the conditions it was created under.
Doesn't browser validate its cache with the cookies it has set?
And is there a workaround for it without setting some GET variables for each request? Another alternative is to tell servers to never cache pages that have such an ERRORS state set, but that would be a hack.
Apparently the solution was to include this as a response header:
Vary: Cookie
This will take cookies into account in caching engines.
EDIT:
There is a problem though: Chrome, Internet Explorer and Firefox work as expected, but Safari and Opera both ignore 'Vary' header when storing and validating cache.
client-side sessions (a.k.a cookies) are probably not sufficient for this scenario...
would suggest server-side sessions instead. Even if Vary headers might work - with $_SESSION you'll be on the save side.
Cache-control: public is probably not what you want. Public essentially says that you're working with static, globally accessible data. It doesn't change per user. It's caching globally because you're claiming that the data is global.
As soon as you start changing per user, caches are having their assumptions violated. 'private' is more akin to what you want.
That will mean that you get less of the good middle-man caching, however. You might be able to hit some middle ground with re-validation, or with appropriate use of Vary headers.
I'm using Codeigniter 1.7.2 with the OBsession library to handle sessions and store them in a database. The app I'm working on consists of a domain (the one with CI) that acts as a service (don't know if this is the correct terminology). Other sites include a JavaScript file from that domain and from there, make an AJAX call to the CI domain. If the site doesn't have a session id, the CI domain returns the one created from that call and then the JS on the site sets a cookie with that session id. From then on, if the site makes any calls to the CI domain it includes that session id in order to identify itself.
This works on every other browser (Mac and PC versions) except for Safari and all Internet Explorers. In Firefox for example, I can see the initial session id get set in the client cookie and in the database and I can make as many calls as I want and as many page refreshes and it still has the same session id in the cookie and database. For Safari, on every page refresh I can see new sessions getting added to my session table.
Any ideas on what is going on here?
Safari and Internet Explorer (with medium security level) does not accept 3rd party cookies by default. A Google search brings:
http://squeeville.com/2010/02/03/third-party-cookies-in-safari-internet-explorer/
Hope this helps.
Obviously the session cookie isn't "sticking" in Safari. Since it's being set by Javascript, you'll have to poke around Safari's debugger (whatever/wherever it is) and see what's blowing up. Perhaps a security model doesn't allow 3rd-party javascript to set cookies, or the browser itself isn't allowing 3rd-party cookies, period.
search for session_start() and paste the logic arround this function...