Difficult to explain this but here goes. I found a similar question in the search but it was for C, not PHP.
I am developing a PHP site which has two logged-in sections, one for employees and one for employers. When either user logs out, their session is cleared, at the moment with "session_destroy()". I also use that at the login page to clear any previous session.
The problem comes if I am working on both sections at the same time. Because they are on the same "site", logging into one logs out of the other. I am forced to use two browsers at a time, one logged into one section and the other into the other.
Is there a better way to end a session when a user logs out rather than "session_destroy()", something that won't affect the other part of the site?
you can save each site's session data in a different part of the session:
$_SESSION['site1'] = ... ;
$_SESSION['site2'] = ... ;
and then call unset on the session you don't want any more:
unset($_SESSION['site1']);
you unset a specific session
unset($_SESSION['variable']);
variable will be the user/admin session value
Related
I have a small situation here but I wanted to try and be sure I was approaching this in a correct way.
I have a web application that is used by several shops.
Each shop is authenticated through htaccess and htpasswd in order to connect to the correct database.
This portion works great!
Each shop has multiple employees but each employee uses a separate computer/workstation.
So it goes Shop logs in, gets authenticated, connects to proper database and then loads a login page.
At the login page the user logs into the application using name and password, and they are good to go.
At this point I am loading user information (UserID, Security Level, etc) into the session.
Part of my problem is trash collection as every once in awhile the session variables are getting lost.
Every page has session start as the first thing so I imagine after an hour or so of inactivity the session is getting collected by the trash collector and poof, it is gone.
I am toying with the idea of loading the user information into the $GLOBALS supervariable to avoid losing the session due to inactivity.
Now, I realize that there are ways to delay/stop the trash collector in PHP but it seems to me if I use the global scope it removes the need for extra coding or configuring of PHP.
Am I correct in assuming that as long as each user is on their own machine accessing the site that using the $GLOBALS will only apply to each user?
Think you have a general misconception of session and global variables.
Global variables are the variables which remain common for the whole
application… Their value can be used across the whole application
whereas Session variables are variables which remain common for the
whole application but for one particular user. They also can be used
across the whole application… But they die when a particular user
session ends.
https://stackoverflow.com/a/14848246/1022914
I recommend using sessions though. Check the user details against user data stored in a database. If it passes authentication, create session variables with user data to be used across your pages. This makes thing a whole lot easier
You can use cache . It can help u to keep user logged in always , as facebook .
I have a log in page which opens a profile page.Now when a user logs in the session is set.But i have not provided log out facility yet.So I can very well open the log in page and log in as a different user , without the sessions and cookies being destroyed.My question is when i log in the second time , which session does the browser use the previous one or the one which has been recently created.The profile page checks whether session is set or not.Can we have two sessions simultaneously for the same website.
Yup i agree with you SAM.
usually session user set for one user in one browser, and it will be automatic destroy by second user when login in same browser. I think it will be more configuration if you want two session with same value. for example facebook and twitter used one session simultaneously.
may be if you don't want destroy first session when second user login you can make function to check session is used or not.
Yes you can have two or more sessions you have to create with different names.
$_SESSION['user1']="some value";
$_SESSION['user2']="some value";
but if you are making only one session the new value will overwrite the previous one.
But it doesn't make sense why you want to login with 2 users simultaneously. You should provide more information.
I have one user portal account. I'm logging into it with two different usernames in two different tabs.
When I do a hard refresh (ctl+f5) in both tabs of the same user account, it opens in both tabs. That can be any username from those two. What can I do to fix this problem?
Session's mechanism uses COOKIEs. COOKIEs are shared between tabs.
If you what to login with one browser session by two differnet users you can disable storing session id in cookie: PHP session without cookies.
Also you can use feature of browsers. FireFox's Private browsing for example.
PHP's sessions. Basic usage.
PHP's sessions. Passing the Session ID.
You cant login on same website on same browser with two different user. Better you use two different browsers.
One option would be to avoid session cookies. Add the PHPSESSID variable to the query string, or have it in the path and use URL rewriting or PATH_INFO to translate /x/y.php/925235a... etc to /x/y.php?PHPSESSID=925235a.... You can actually tell PHP to do the first for you.
Note, in order for this to work, you'll need to say something like
ini_set('session.use_cookies', false);
or the like, in your script before calling session_start(). Then PHP won't send session cookies; in most cases it will just transparently rewrite URLs in your page to include the session ID, so you get the first option for free.
The biggest drawback to this approach is that it makes your users vulnerable to an attack called "session fixation". If i hand you a URL that already has a session ID, and you click it and log in to the site, you've logged in my session for me and i can now visit the site as you. One way around that is to switch to a new session when someone logs in...but if your app is a shopping cart, it can be annoying making people log in to buy something.
Second biggest: If a user follows a link that doesn't have a session ID, PHP won't recognize them. (The user can use the "Back" button to get back to a point where they have a session ID, but that sucks usabilitywise.) You have to ensure that the session ID appears in every link or URL. Fortunately, PHP will rewrite most of them for you, but any links you generate with JS and such, you'll have to do yourself.
Users log in, and a session variable is created from their username. The menus on the site are determined by the users status - admins see an admin menu, coaches see a coaches menu, etc. All that works fine.
Things break down when I need to use the $_SESSION['value'] thing again to pass something from one page to another. For example, a coach will log in and see a list if his games that he has created. To edit the games, he selects one game,a variable is then passed to the next page where he can edit the details of the game he selected on the previous page. the minute the form is submitted on the first page (when he selects the game), its like my session is broken, and I lose all the menus etc.
Other forms on the site that simply add things to the database (users, games, etc) that do not need $_SESSION to pass anything work fine.
Is there something obvious I am overlooking? Is there another method of passing info from one page to another that wont break my session?
This sounds like the so often...
"oh shit, I forgot to call session_start (); before using $_SESSION"
But there are of course many other things that might cause this kinda headache.
check to see that the page your form submits to uses the same (or lower down) sub-domain (if your site uses www everywhere but not there, the cookie holding the session info won't be doing it's job).
check to see that you aren't using https on some parts of your site and http on others
make sure that the TTL (experiation) of the session cookie is long enough so that the user has time to do the edit (this normally isn't a problem, I have yet to come across it with a default configuration)
make sure you have session_start() on all your pages; including the one your form is submitting to
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.