Php uses session to store a cookie on the client side and than matches that cookie name with a file on a server. Example:
PHPSESSID=kbn5gncbf1783uv4kpbg84gdq8
matches with the file (A FILE, not DATABASE) in
/var/lib/php/session
This means all the serverside cookie data is stored in files. Imagine having 50000 users on your site using persistent sessions (that don't get deleted after browser restart). This means 50000 files in /var/lib/php/session. How big of a performance hit are my users getting because the server needs to find and open a file on my harddrive?
Is it better performance wise to use regular client side cookies and then see if that cookie corresponds to a registered user entry in my database?
Related
Who creates a session and how does cookie and any role in it?
I was asked this question in a company's interview process and didn't know the answer. I would like to to know which side creates Sessions i.e whether the client side or server side and does cookie has any role in it.
Also how the server understands which session is provided to which client and which user of client if multiple users are logged in?
What’s the difference between a cookie and a session in PHP?
PHP sessions improve upon cookies because they allow web applications to store and retrieve more information than cookies. PHP sessions actually use cookies, but they add more functionality and security.
Sessions store data on the server, not on the browser like cookies
The main difference between a session and a cookie is that session data is stored on the server, whereas cookies store data in the visitor’s browser. Sessions use a session identifier to locate a particular user’s session data. This session identifier is normally stored in the user’s web browser in a cookie, but the sensitive data that needs to be more secure — like the user’s ID, name, etc. — will always stay on the server.
Sessions are more secure than cookies
So, why exactly should we use sessions when cookies work just fine? Well, as we already mentioned, sessions are more secure because the relevant information is stored on the server and not sent back and forth between the client and server. The second reason is that some users either turn off cookies or reject them. In that scenario, sessions, while designed to work with a cookie, can actually work without cookies as a workaround, as you can read about here: Can PHP sessions work without cookies?.
Sessions need extra space, unlike cookies
PHP sessions, unlike cookies which are just stored on the user’s browser, need a temporary directory on the server where PHP can store the session data. For servers running Unix this isn’t a problem at all, because the /tmp directory is meant to be used for things like this. But, if your server is running Windows and a version of PHP earlier than 4.3.6, then the server will need to be configured – here is what to do: Create a new folder on your Windows server – you can call it something like C:\temp. You want to be sure that every user can read and write to this folder. Then, you will need to edit your php.ini file, and set the value of session.save_path to point to the folder which you created on the Windows server (in this case, that folder is under C:\temp). And finally, you will need to restart your web server so that the changes in the php.ini file take effect.
Sessions must use the session_start function
A very important thing to remember when using sessions is that each page that will use a session must begin by calling the session_start() function. The session_start() function tells PHP to either start a brand new session or access an existing one.
How session_start in PHP uses cookies
The first time the session_start() function is used, it will try to send a cookie with a name of PHPSESSID and a value of something that looks like a30f8670baa8e10a44c878df89a2044b – which is the session identifier that contains 32 hexadecimal letters. Because cookies must be sent before any data is sent to the browser, this also means that session_start must be called before any data is sent to the Web browser.
link-1
link-2
link-3
link-4
The server creates the session and sets the cookie, which is stored in the client's browser. The cookie contains a session identifier (a string of characters) that allows the user to access a particular session on the server. This session identifier corresponds to the session on file.
What's the best way to search if a PHP session has been created on the server?
For example, store the name Joe somewhere in a session, and then after Joe closes his browser, can I then lookup (in a php script elsewhere on my computer) if Joe's session still exists on the server (i.e. not yet expired)?
Session data is usually stored in the server's temporary directory (the session.save_path setting).
While it is theoretically possible to search through that directory, go through every session file, open it, and look for whether it's Joe's session, it's not a clean approach, and there are many ways it can break - for example if the server doesn't give you a list of the files in the temporary directory to start with. Or what if a user has multiple simultaneous active sessions?
If you really need this, you should probably create a custom session handler that stores its data in its own directory or database. For that custom handler, you can then implement an interface that allows you to query whether a certain user is logged in, or a specific session exists.
In the server the check the path set to store sessions in php using directive session.save_path
and then try decode the files in there using session_decode() method
More information can be found in below links
Location of session files
Reading Session Data
I would like to know where PHP session data is saved; is it in client browser? or on the server?
When I disable cookies in my browser setting, PHP can't save session data, but in php.ini, I can change the session save path.
Is session data stored on the server or client browser?
The session data that you read and write using $_SESSION is stored on server side, usually in text files in a temporary directory. They can not be accessed from outside.
The thing connecting a session to a client browser is the session ID, which is usually stored in a cookie (see the comments for exceptions to that rule). This ID is, and should be, the only thing about your session that is stored on client side.
If you delete the cookie in the browser, the connection to that session is lost, even if the file on the server continues to exist for some time.
The session.save_path variable influences the location on the server where the session data is stored. If you are not the server's administrator, it is usually not necessary to change it.
It's both! A session saves the actual session information on the server, but gives an identification cookie to the client to know which session belongs to which client. The information in the cookie itself is worthless, but allows the server to identify the client and use the actual session information.
Blockquote "Is session data stored on the server or client browser?"
It makes me think of a valet parking system. The valet (server) keeps your car (session data), but he/she gives you a ticket (session id) to hang onto which proves that the car is yours when you need access to it. If you lose your ticket (by deleting your cache, or closing the browser), your car (session data) is as good as gone since you can't prove it's your car anymore.
Okay, it's just an analogy...and breaks down quickly. E.g. you don't actually own your session information like you do your car. And you don't get to drive it away.
Both, the session in the client(browser) is saved as a cookie. This cookie references a session which also resides on the server.
It is stored on the server side to maintain security; but additional cookies could be also stored on the client side.
Session ID is stored on the client in a way that usually dissipates when the browser is closed (stored as a cookie?).
Session ID and associated data is stored on the server (where?) for each client that starts one.
The main thing I wonder about is how the server knows when a session has ended, though. If the client no longer has the session ID stored (say, after closing their browser) and they try to ask the server for another session, it starts a new session. Does the server know to garbage collect the previous session data after some set amount of time? It seems to me like something that could be abused...
Session ID is usually stored on client browser using a cookie (alternatively, in URL parameters, but this is not recommended, as explained in http://php.net/manual/en/session.security.php)
Sessions are stored in the directory defined by session.save_path (e.g. /var/lib/php/sessions), or the system's temporary directory if this is not set (usually /tmp).
Sessions are garbage collected periodically, either by PHP itself during a request, or by a cron job (e.g. on Debian this is the default). See http://php.net/manual/en/session.configuration.php#ini.session.gc-probability
The main thing I wonder about is how the server knows when a session has ended
He doesn't know. However he knows when a session has not been used since a certain period of time, so it can delete unused sessions.
Does the server know to garbage collect the previous session data after some set amount of time?
Yes. This is defined by the session.gc_maxlifetime ini setting. Any session older than that will be deleted during a garbage collect. Garbage collect frequency can be tuned with the session.gc_probability and session.gc_divisor ini settings. (See doc.)
It seems to me like something that could be abused.
If you mean that someone may be able to create too many staled sessions on the server; yes this is probably true.
what you describe is perfectly right. And yes, it can be abused easily. There's even a tool out that automatically hijacks sessions around you (search for firesheep). The sessions are usually stored as either SESSION cookies or are passed between sever and client each time.
Check the PHP for a very brief intro, and some google on session and security will get you further.
Sessions expire automatically and are cleared up depending on the settings (after 20 days of no usage for example) and they are stored on linux, usually under /tmp/
Check php.ini for more information
That's about all that I need to ask
I am dealing with a site right now and I can't see a really significant difference in storing my sessions in a database table over and not doing so.
There are a couple reasons why I sometimes store session data in a DB. Here are the biggest two:
Security Concerns on a Shared Server If you're running on a shared server, the chances are that it's easy for other users of the server to meddle their way into your temp directory and have access to the session data you have stored there. This isn't too common, but it can happen.
Using Multiple Servers If you're upscaling and using more than one server, it's best to store the session data in a database. That way the data is easily available throughout your entire server stack (or farm depending on how big you're going). This is also attainable through a flat file system, but using a database is usually a more elegant, easy solution.
The only thing I can think of for not using a database is simply the number of queries you'll be running. For each page load, you'll have an extra query to gather the session data. However, one small extra query shouldn't make that much difference. The two points I outlined above outweigh this small cost.
Hope that helped a bit.
On a shared host when you have no control over who can access the directory where session files are stored. In this case storing sessions in the DB can offer better security.
And one scenario with which I have no experience myself, but I believe is a realistic scenario:
On a loadbalanced server farm where subsequent requests of one user can be dispatched over multiple servers. In this case you could choose to have one central DB server. In such a scenario, if you wouldn't have such a centralized session repository, session data of users would get lost because they could switch servers per request.
There is a huge difference when you are using several servers, with a load-balancing mecanism that doesn't guarantee that a given use will always be sent to the same server :
with file-based session, if the user is load-balanced to a server that is not the same as the one which served the previous page, the file containing its session will not be found (as it's on another server), and he will not have his session data
with databased-based or memcached-based sessions, the session data will be available from whatever server -- which is quite nice actually, in this quite of situation.
There's also a difference when you are using some shared hosting : with file-based session, if those are placed in the "temporaty" directory of the server (like /tmp), anyone might read your sessions files, depending on the configuration of the server. With DB-based sessions, this problem doesn't exists, as each user will have a different DB and DB user.
In addition to the above posts:
Database sessions (when session table is of Memory type) are faster.
When using file-based sessions, session file is locked until script ends. So, user cannot have two working at the same time scripts on server. This matters for example, when you write a download server. User downloads a file, script sends file to him, leaving session file locked. And user cannot at the same time browse the contents of file archive.