I'm writing an app using Zend Framework and I need to be able to logout users on demand. The app will receive a request containing some kind of ID's that are mapped to SessionIds and it will end/expire those sessions. I know how to do the mapping, but what then? How do I end a session having its ID?
I see that there is Zend_Session::setId(), but I don't think this does what I want to do.
I have an idea to just delete files that are associated with given session, since they are named sess_[sessionId], but I guess that is an ugly way to do it.
You can save session info to the database. It would be related by session id.
Then create a plugin that checks if the DB row still exists. If not, then execute Zend_Auth::getInstance()->clearIdentity()
The method that logs the user out would delete the session from DB.
Depending on the structure of your sessions and what exactly you are trying to clear, there are a number of ways to destroy, expire and unset Zend_Sessions. Please refer to http://framework.zend.com/manual/1.12/en/zend.session.html for further information.
If in the future you could provide more detail and perhaps a bit of code illustrating your issue I'm sure the community would be more then happy to provide a better answer.
Good Luck.
Related
I have seen many similar questions on the overflow, but none of them really addressed my scenario hence I am opening this question.
I am working on a project where there is database of thousands of mp3 tracks and mixes. Each mp3 file has an id and associated information on database. Now a shopping cart is being build in a way that user can select tracks and add to the cart. When a track is being added to cart its id is stored in the session and this works fine.
Now the problem arrives when there is large number of id's stored in a session. A session being a cookie [codeignitor] , I know it has 4kb of storage.
What will be the best practice to get this data preserved? I know that I have to change my strategy and move out of using session.
I tried using database [mysql], its not only slower but also has several issues, like each new user need to have a row added to database tables, how to clear these tables after use.. etc etc.
I tried using memcached but I believe that is not the right choice since the data that I am trying to store is not that huge. Also memcached has several issues on windows platform, provided I am not sure if the client will deploy it on a linux / windows server.
I need a native cross platform solution. I have done quiet a lot of research and did not find a reliable solution yet.
I use codeigniter framework, hence you can suggest any PHP or codeigniter solutions, thanks much.
You talk about storing things "in the session" so I assume you're using PHP's session handler, not setting cookies individually.
In this case, the session storage is all done on the server side, so a 4k limit does not apply. Take a look at your http headers during a request, and you will see only something like this:
Set-Cookie: PHPSESSID=1234abcde56789f
This session ID refers to a file (typically stored in a directory, e.g. /var/lib/php/session/ on RHEL distros) which contains the actual data as a serialized PHP object.
Why dont you try setcookie() function in php?
you can store as much amount of data you want in the cookie,and store the refrence to the session in database!
hope you will understand my answer!
what miken32 is saying is correct. And if you are using Codeigniter, then set up a session database table and use codeigniter sessions. if you use a db table then its just an id which is set on the cookie. be sure and start with the official codeigniter session db table so it works properly.
codeigniter session class has built in 'garbage collection'.
all explained here, scroll down for the database portion:
http://ellislab.com/codeigniter/user-guide/libraries/sessions.html
Using a native PHP session is the right way to move, as the fellow users answered a php session stores only id on to cookie, But codeignitor behaves differently, it stores all the data on to cookie and this is where the catch is.
Moving on to normal PHP session was a pain because I have to change the codes allover the project. After a little research and testing I have come to a conclusion that [Native Session library for CI][1]
[1]: https://github.com/EllisLab/CodeIgniter/wiki/Native-session by Derek Jones is an awesome alternative to use PHP sessions over CI with the same CI session functions and syntax.
So to conclude , Either use PHP sessions from the scratch or use this library as an alternative to overcome CI session size Limitations.
I'm a little beginner to PHP and currently doing a project work that involves the task of displaying sessions that are currently live. But, I read in the documentation that sessions were stored in tmp folder and will be automatically expired when the browsing session ends. So, what can I do — I also googled and found that it can be stored in Databases and then we can get the count?
Was that possible? If so, please give me the methods for that.
Update: Also, please give the way such that entry in the database must be automatically removed when the session ends
I would suggest you define / let your stakeholders define what information you are after. If it is the technical webserver-number of current active sessions than you can keep on looking at what you are doing, but if you are looking for "number of users on the site" for instance, you should step away from the PHP-concept of sessions. They are something else.
Instead, as saving all this can be somewhat tricky, take a look at the "realtime" functionality on google analytics, maybe that'll be enough.
If that isn't, you need to make a database, register each load and update the loading-time on each action, so you can check out if someone was active during a certain period
I am initially seeking guidance to make sure I go in the right direction. From there I will come back with the code and ask for further assistance. I realize it isn't cool to say "hey I dont know what I am doing so I want you to do it for me."
So, here is my situation. I would say my php skills are amateur, and I am looking to increase them by working on projects for myself so I can learn through practice and application. I have created a webpage which contains a form that is used to update a XML file (I am playing around with flatfile DBs at the moment). All works well, the file is updated and the users is brought back to the page and the updated file is displayed. What I would like to do is allow the user to receive an update while they are browsing the website that the XML file has been updated, as well as alert them to the file update if they are returning to the website after having left.
My thoughts are that this would be done by using php session variables, one when they first access the website and another when the XML file is updated by a user. For the one when they access the site I thought a variable with a unique ID and timestamp as well as a timestamp of the files lastmodified value. I realize that this requires keeping storage of the session values since the value will have to be compared to something or else it will always appear as the most recent version, hence no changes.
Now that I think about it I guess you wouldn't need a session variable created on file update since the comparison will be based on the lastmodified value.
Just want to know if I am on the right track or completely off-base.
Any input is greatly appreciated.
Storing the lastModfided value
For your specific case I hope i understood you right. You want to say "notify the user if he wasn't the last one to work on the file" right?
That should be easily doable using the session as after writing you could store the last modified date of the file in the session and them compair that when the user comes back. I don't see any issues with that approach.
If you have you users log in I'd much rather tie the notification to their accounts.
Your session files will be deleted if the user is way for to long and a new one will be created if he uses a different browser. So it would be a really instable way of giving notice.
For the notifications no matter where he is on the site
If your database is updated in the background and you then could like to create a notification for the user I'd advice again using the php session for that.
While you are able (using some rather ugly hacks) to edit the session files they are not a stable enough basis to implement a notification system.
If you just work of session cookies then I'd still just store a "notify this session id if the guy shows up again" somewhere and check those notifications on every page load.
I know this is not as performant/nice/cool but it shouldn't really matter and save you a lot time dealing with.
Hope i understood you right and it makes sense to youu
I've got a php application and I'm saving the session variables for the user using $_SESSION itself. Is there any particular advantage of storing it in a database?
I'm looking for a reliable / well-researched article which talks more about this. I havent been able to locate anything yet.
The advantage you have of storing it in a database is that the data exists as long as you want it to exist.
Your browser will destroy the session according to how it is setup, which makes it a bit unreliable. I can't however find an article on this yet but this is what I use as a convention for a situation like this.
Any data that needs to be stored long term, like user details and activity I store in a database. Any data that is only relevant to the current workspace, like logging into a site and posting a few comments etc. can be stored in the session. For instance I store user authentication details in a session to constantly check whether the user is logged in or not and whether to redirect him/her to the correct page.
This works wonders when checking access rights throughout your application.
For me its much safer to store user details in a database because it cannot be publically accessed like the $_SESSION.
Please disagree with me if you want to though.
I would say storing in database is better.Because
When you are hosting your site with a shared host
PHP uses the same path for storing sessions for all the users,somewhere that is not in your folders.
You can track the users and their status easily.
For application that are running on multiple servers, you can store
all the session data in one database.
This article may help.
Well this is a question for the ages. Personally from what I have learned in my time. Unless your site starts booming on a massively large scale where you need to start using multiple servers for various aspects of the system such as load balancing where you have many mirror systems running. Or need to improve performance a little for an over populated system the benefits of using DB related sessions or File based sessions really isn't any different.. Grant it I could be wrong this is merely my own personal perception off my own experiences. Just like you Ive never really found any articles, posts, other that really put either to the test side by side hell I don't even think I have found anything that really puts either to the test stand alone for that matter. Personally I just go with what ever the need is (or desire of my client) usually I just stick to native sessions file based.
I hear they can be spoofed, but have seen no proof to that notion to date. So other than that potential I stick with file based. Unless I am using a system like code igniter then sessions seem to handle better DB driven with it rather than not.
At some point in time you're going to have to store something in a session. Whether it's all the session variables or just the ID of a row in a sessions table. That being the case it would be fairly easy to alter the ID stored in a badly encrypted session and hijack a different session.
Consider this:
Full Session Option. This has the User ID, Username and an encrypted and hashed password stored so that every time a page is called it verifies my login. To hijack someone else's session I'd have to know their User ID, Username and Password Hash and be able to overcome the sessions inherent encryption.
Session + DB Option. This just has a Session ID stored that references a row in a database. All I have to do to change the session I want is to break the encryption on the session and say add one to the Session ID. I'd then be authenticated as the user that logged in after me.
You could store login details in a session and then any none login related data in a session table if you have a lot of extra information but then again you might as well just remove the need for an extra table and extract the data from whatever relevant tables you need.
From my short experience, you should store in $_SESSION only data that you will NOT need to be refreshed in all sessions opened by a unique user in different devices.
(mobile/desktop/etc.)
In other words, data that you are sure will never change like a userID.
For example, I had stored the user profile picture path into
$_SESSION and it led to a strange User Experience. When changing the
profile picture in a desktop, it did not refresh the profile picture
for the user on his mobile. Other users saw the new picture though.
Indeed, the path was refreshed into the DB but not in the $_SESSION.
Login-out and Login-in would not change anything.
Remember that the default behavior is that $_SESSION passed with cookie will be different for each browser even if this is the same user logged in. You will have to do a session_destroy() to avoid being stuck with old data.
Very temporary data may be stored in $_SESSION as well I guess.
NB: the basic need of global session, out of these arguments, is to have variables available globally
Just looking for some ideas and maybe feedback on what I have at the moment.
A website that has standard access using a generated 'session id' stored as a PHP
session. This is alwazs passed as a GET method and checks if the user has been active for the last 10 minutes.
Otherwise unset and log out.
Problem I have if a mobile application accesses the same information in a similar manner... is it best to use the session id's ... as it can become annoying if suddenly your session runs out in a mobile app, esp. if the app has been left open.
So I thought of using a dev key. What is the best way to use a dev key for third party access? Is it to simply override the session key - i.e constant log in? or is it maybe best to use both?
Thanks in advance
I wouldn't suggest using a GET parameter to maintain sessions. It can leave you vulnerable to attacks. If you really want to do it make sure you generate the session IDs randomly. But whenever I want sessions I use PHP's built in session functions
You would manage a distributed session using db. You create the same session data on a table, then, the differents clients can ask to the db if exists a session open. You can try that using different status from the session.
In that way, you can use the table to persist the session data, but use the built in php sessions functions, like #Adam Lynch says