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.
Related
I'm new to PHP, I read other articles without finding the answer I'm looking for, but still don't know if what I want to do makes sense or not.
I'm using PHP 7.
My user authentication page, checks credentials and then executes session_start(), creating the session server-side and a cookie client-side in the browser.
Each other page of the web application then calls session_start() to resume session information, in this case checking the cookie. Everything works fine so far... at least when I have a single login.
I'd like to be able to have more than one user SIMULTANEOUSLY logged in the same browser (on another tab for example.) using cookie. I don't want to append the session ID to the URL.
I managed to create different session on the server-side using session_id() before session_start() in the authentication page based on username, but the problem is on the client side.
The first successful login (session_start()) creates a cookie and the second login updates the same cookie corrupting the previously created session.
Therefore when it comes to resume the session, session_start() will resume only the last session, mixing the data fetched from DB based on session info.
Is there a way to make session_start() create a cookie for each login and make PHP resume the correct session using cookies?
Any ideas?
FURTHER DETAILS:
I'm updating a legacy app trying to fix some security issue. The need for multiple sessions comes from administrative purposeses where admins access the same site. The reason why it's needed a separation of session is that depending of the session info, the data are fetched from a different database. Therefore, a regular usage would only need one session per user, but the administrator he needs to make multiple logins viewing different data depending on that login.
The default PHP behaviour is to handle sessions using cookies.
..and the default behaviour for browsers is to "reuse" the same set of cookies if you revisit an URL in another tab.. So, like mentioned below:
The simple way probably is to start another browser. Not the same browser but like firefox and chrome, if you have multiple browsers installed.
Another way would be to install a browser plugin, like Sessionbox for Chrome or Multifox for Firefox.
Edit, for clarity: I can think of two cases when multiple sessions would be used:
During development. Depends on the application, but an obvious case would be testing communication between two users.
After deployment. Though I've never seen a site that required multiple logins for the same user account.
This is my frame of reference. Based on this I assumed the question was for development. I'm not suggesting that the site should require installing extra packages. Flash would be about the only one that's ever gotten away with that..
You can use the same session but change the variable names that you are looking for:
if ( $_SERVER['REQUEST_URI'] == '/admin/' ):
$session_name = 'session1';
else:
$session_name = 'session2';
endif;
session_start( $session_name );
It's a php based web store without user logins because all of the payments are handled via paypal. My question is what would you guys suggest for the shopping cart - cookies, sessions, or both? I'm not too concerned with the longevity of the shopping cart's contents be I'd like for the user to be able to click around and do a few things before they commit the order. I'm leaning towards sessions because some people may still disable cookies on their machines.
PHP sessions use a cookie with the session id to track the user. I would go with sessions since it will handle all of the identification for you and make things easier and more transparent.
It is also possible to use sessions with no cookies and it will pass the session id around in the URL. That in some cases can be a security risk, but perhaps not so much in your situation.
By default, PHP sets a cookie on the visitor's browser to know which session id to use anyway, so the only real difference between the three options in the end would be how much data gets sent up to your server during the request.
That being said, you can also use sessions without cookies by making sure to add ?session_id={session_id();} to all of your internal links and the following to the beginning of every page:
if (isset($_GET ['session_id'])
session_id($_GET ['session_id'])
session_start();
So, recommend using sessions.
I have created a mobile version of a site. It uses the CodeIgniter session to store some data. This seemed okay on Blackberry a few weeks ago but now it is making multiple sessions on every page and therefore it can't access the session where the data is saved. This works fine on the desktop and iPhone. The cookies are being saved to the Blackberry. I've got it so that it using the database to save the data.
On every page it checks to see whether the phone is touch screen to show the page differently. There is also some other data. It's all being saved but into many sessions.
It's on a subdomain - m.domain.com so I'm wondering if the domain name for the cookie might need to be set differently.
EDIT:
I managed to sort it out by saving the session id in a different cookie and then calling that in a query to get the info. Thank you to the person who replied.
do you proceed you session-id on every link and every form? if not, and the client doesn't accept cookies the session will be lost on every new page load - exactly what you're describing.
EDIT: to correct that, take a look at the documentation (+ Passing the Session ID) - just add the SID-constant to all you links and forms, it will automatically be empty if the browser accepts cookies, so the url isn't that ugly for those clients.
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...
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.