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.
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 );
1 year ago, I've made a PHP social network which works pretty well. Via browser, once the user logs in, i use the $_SESSION variable to store credentials and remember the user through all pages. Everything works well.
Now i'm trying to build the app version of the website, using Phonegap and jQuery Mobile. At first glance i tried to use the same approach: to manage user login i implemented a simple form with Email and Password, which sends an ajax request to a "check_login.php" file.
If email and pw are correct, i "login the user", which simply means i store everything in the session variable, as i always did.
What i noticed, which is driving me crazy, is that using this approach data are not being stored into the $_SESSION variable. Using my app, each time I send an AJAX request to the server, the $_SESSION variable is gone and it looks like login data are not stored. Like i never logged in. (Of course, i've put session_start() at the top of each page). Moreover, each time i send an AJAX request to the server, the session_id() changes.
Is that normal? Does this mean with Phonegap i can't rely on $_SESSION variable or I am just missing something?
If yes, why?
The largest problem with this approach is that a pure PHP session will expire in a short period of time (the default is 24 minutes). So you're making inconsistently spaced calls that could cross that boundary of time.
There's a couple of ways around this
First would be to change your session handler to save the sessions in something more long term (like a database). More overhead but you could retain the session ID for a longer period and store it within your localStorage.
The second would be to directly tokenize your logins. So a user logs in and gets some random hash back (i.e. md5(uniqid(mt_rand(), true))) that serves as their token. Then your app contacts a special page and passes that token and you can check it in your token table. This would afford you more control over your logins. You could expire the tokens at will and would not be at the same mercies of PHP sessions.
I have a url shortener that I created to track incoming links. Currently the php sets a cookie and inserts visitor information into the database. It attaches an id to the redirect url and redirects the user to the website.
The website has javascript on the page that takes the id and tries to set a cookie on the front end. If cookies are disabled, the javascript attempts other things to store that id. The reason I am setting the id is due to the javascript sending random pieces of information to the backend.
Is there a way for php to have a fallback if the person doesn't have cookies enabled? I don't want to create a new database entry for someone who visits the same link multiple times who doesn't have cookies enabled. Don't want to be tracking the same person as 2 or more people.
Edit
If I can't prompt the user that their cookies are disabled, are there any alternatives?
2nd Edit
One of the comments brought this up, so I thought I'd post the link here: User recognition without cookies or local storage
I'm in the process of setting up various authentication methods on a project I'm working on, and the common OAuth 2.0 framework that Google and Facebook use seems pretty awesome. Reading the example Facebook gave though, I stumbled across something that seemed strange to me.
If you look at the bottom of that facebook page, you can see an example in PHP. In their process, they first set a random string to $_SESSION['state'], then redirect the user to the facebook authentication page, which then sends the user back to the original page, where they compare the state string to what's supposedly stored in the session variable. Maybe I'm missing something here, but don't you lose all session data if the user leaves your site? How does this work? How is your session data maintained even though you leave the site?
The session data stays until you close the browser or logout from your app. The session state could be getting saved on the server or on the browser in a cookie. Either way, the session data is available to you once facebook redirects back to your site.
You don't lose your session data, when user leaves your site.
So, we check state value after user is redirected back to our website from facebook.
I'm working a site where users could technically stay logged in forever, as long as they never close their browser (and therefore never get a new session key). Here's what I could see happening: a user leaves a browser open on computer A. The then use computer B, login and change their name which is stored in the session. They logout of B, but A is still logged in and still has their old name stored in the session. Therefore, their name won't be updated till the next time they logout manually or they close their browser and open it again and are logged in through the remember me function.
Name is a simple example, but in my case the subscription level of their account is stored in the session and can be changed.
How do you deal with this?
A few ideas that I have are:
After a period of 10 minutes or more, the session data get's reloaded. It might be exactly 10 minutes if the user is highly active as the function will get triggered right at the 10 minute point or it could be after 2 hours if the user leaves and comes back and then triggers the functionality.
Store as little information as possible in the session and load the rest from the DB on every page call. (I really don't like this idea.)
Use database sessions and use the same session on all the computers. I like this, but I could see it getting confusing when something like search criteria are stored in the session--the same criteria would show up on both browsers/comptuers.
For information, even such as the user's name or username/email address, store it in the session, but for other information that would heavily affect their abilities on the site, don't store it in the session and load when needed (attempt to only do it once per instance).
Are there other better methods?
--
Another option: 5. Use database session and when an update is made load the user's other sessions (just unserialize), change the relevant information and save them back to the database.
I would go either with number 1 or number 4. If you store the time of the last update of the information, you could even ask on every request whether the date has been updated.
Don't store information likely to change in the session, if you're looking at scenarios like the one you outline. Just get over your dislike of loading user data with every page - it's by far the best idea.
I'm guessing you don't want to load the data from the database because you're concerned about performance issues somehow. Before you try out any of the other solutions, you might want to test how long it takes to actually load a users data from the database, then check that against your number of users - chances are you won't see any performance problems due to loading user profiles on every page.
Regards
I'd go with option 6: only store userid and session specific stuff (search criteria) in his session and put the rest into APC/xcache (memcached if you're using multiple servers).
this way you'll only have to go to the database the first time (and after the cache expires) and you can still share any data between users sessions.
Normally you should do 2), but you don't like it.
maybe you can use sessions stored in db.
when a user change his name, put into all sessions from that user the information "refresh userdata".
on the next request the userdata is reloaded again into the session and is cached there.
this can be done be reusing your loaduserdata function which called at login.
php session_set_save_handler() - also read comments
php session_decode() - to read the username from the session to store it additionally to the sessiondata. usefull for easily to find the users sessions for updating.
[edit]
don't forget:
when you are updating all the sessions while the page is generated (between session_start and session_write_close) you changes maybe lost.