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...
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 );
I'm in the process of building a single sign-on system and I am using cURL to send a request off to a file on the main site and return the results / their user data; however, if the user logs into the secondary site via a cookie (ie; they aren't currently logged into the main site) I need to make sure they get logged into the main site at the same time and set some session variables so that they don't continuously have to keep logging in via a cookie on the secondary site.
Obviously we normally would end up with a different session id on the file I am calling via cURL and hence setting any $_SESSION variables there wouldn't be available to the secondary site; so I tried passing the session_id from the secondary site with the call via cURL and then in that file I did this to set the session id so that any $_SESSION variables I set there would then be available to the secondary site.
// Get session ID
$sid = trim($_GET['session_id']);
// Set the session id so we can get the added session data below via the forum
session_id($sid);
session_start();
However when I do that and try and access the secondary site the page won't load, it just hangs - I tried removing that code and loading it again but it won't load until I restart Apache.
Btw.. if it matters, this is on my local dev machine, which is Windows XP Pro.
Any ideas!?
I’m assuming here that both your main and your secondary site are on the same server and use the same session settings, especially the same session.save_path, is that correct?
If so, that’s where your problem lies:
The default session handling mechanism of PHP works using files to save the session data.
And to avoid concurrent write access to the session file, the file gets locked as long as one script (one script instance would be more exact) is still working with the session. Every other script that wants to access that particular session has to “wait”, until the first one is finished using the session.
So with you trying on your secondary site to start your session with the session id already in use on your main site, the script on your secondary site can’t access the session because of that locking.
And since your main site’s cURL request is waiting for the secondary script to finish, which is itself still waiting for access to the session … you’ve got yourself a nice deadlock here :-)
What you can do, is call session_write_close in your main site script before making your cURL request – at that point all data is written to the session file, and the file lock is released.
You have to be aware though, that you can not use the session again in your main site script instance after that – well, you can still read data from and push data into the $_SESSION array, but since the session is already closed, all data that you alter in that array after that point will not be persisted any more. So do what you have to do with the session in your main script, then close the session – and then make your cURL request.
Edit: Well, come to think about it – not sure if the above actually helps here … because your whole approach might be flawed already. Calling a script via cURL on your secondary site will not actually set a session cookie for your secondary domain in the user’s browser – because every response of that secondary site’s script does not “land” in the browser, it lands in your main site script, because that’s where you doing the request from.
I think what you really need here, is to call a script from your secondary site in the user’s browser (JavaScript/AJAX request, iframe, embedded image), so that it’ll set a cookie with the session name and session id as value under your secondary site’s domain – only that will make PHP able to “recognize” the user’s browser once they navigate to your secondary site. Actually opening the session will not be necessary (still assuming that both sites use the same session), because the session is already started, and all it needs for PHP to pick it up on the secondary site is a matching session id from the cookie.
So try doing that instead – but be aware of the problems you might run into with that, since the browser will consider the cookie for the secondary domain as a third party cookie when you are trying to set it in the context of your main site (and the domains don’t match, e.g. one is not running on a subdomain of the other or something like that).
How can I realize a parallel session with PHP? I intend to login in as admin and now I can see a list of normal users. The admin user should be able to log in as a normal user in a new browser tab by clicking a user.
I tried to give sessions a unique name and id but this still haven't work.
Session cookies are stored in the browser for the whole browser session, so you can't separate them between windows.
Either you write your own session handler code, that does not use cookies, but appends something like '&sessionid=BLARGROB' to every link, or just install two browsers on you machine. Use Internet explorer for your user session and Firefox for your admin session, and Chrome for whatever else you'd like to do on your site without invalidating the other sessions. Using several browsers is a good idea to test your layout anyway.
Situation:
I have a Javascript/jQuery web app which communicates with a PHP/MySQL/Zend Framework 1.12 backend. The web app runs inside an iFrame (loaded with jQuery fancybox in iframe mode).
The application creates an object on the backend and saves the current session ID with it. It then displays the object's properties on the front end and modifies the object on the backend through ajax calls when the user interacts with the application. The session ID is used to check if ajax requests are coming from the same user (user is not logged in so it's the only way to check).
I use jQuery to do the ajax calls and Zend_Session to work with sessions in PHP/Zend.
Problem:
Now, the problem is that in safari 6, these ajax requests have a different session ID so they don't match the session id stored in the backend model object and access is denied.
This does only happen when running in an iframe, not on any other browsers, not on other versions of safari (5 or below)
Does anyone have an idea what can cause this and how to deal with it?
Some more info:
The entire application runs in the iframe, the call from which the session id is stored in the backend model as well. So I'd think all these calls have the same session id.
Another thing: once I run the application in a separate tab, and then in the iframe again, the issue disappears: from then on until I kill the browser session I get the same session id every time as I would expect. That smells like a bug to me, frankly.
The key issue is the iFrame. As a part of the Safari security model, requests running in iFrames are treated separately from the rest of the page requests. It's part of their 3rd party cookie protections. As I understand it, Firefox22 is going to start doing the same sort of thing, but not quite as restrictively.
If you're sure you really want to get around this, pull PHP's Session Id cookie out and put it on the query string for the request to the iFrame. You can then pull the session id from the query string and use that one. (You won't end up with one in the cookie data if you do this.)
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.