Differencebetween Sessions and Cookies in PHP

What is the difference between Sessions and Cookies in PHP?

A cookie is a bit of data stored by the browser and sent to the server with every request.

A session is a collection of data stored on the server and associated with a given user (usually via a cookie containing an id code)

Cookies vs. sessions

The concept is storing persistent data across page loads for a web visitor. Cookies store it directly on the client. Sessions use a cookie as a key of sorts, to associate with the data that is stored on the server side.

It is preferred to use sessions because the actual values are hidden from the client, and you control when the data expires and becomes invalid. If it was all based on cookies, a user (or hacker) could manipulate their cookie data and then play requests to your site.

Edit: I don't think there is any advantage to using cookies, other than simplicity. Look at it this way... Does the user have any reason to know their ID#? Typically I would say no, the user has no need for this information. Giving out information should be limited on a need to know basis. What if the user changes his cookie to have a different ID, how will your application respond? It's a security risk.

Before sessions were all the rage, I basically had my own implementation. I stored a unique cookie value on the client, and stored my persistent data in the database along with that cookie value. Then on page requests I matched up those values and had my persistent data without letting the client control what that was.

Difference between Session Cookies and General Cookies?

This is an implementation detail of the website, so this can't be directly answered.

The session cookie may be created server side and associated with the saved session, but it still has to be saved client side so that the client browser can remind the server which session to use (and verify it).

From the browser's perspective, there is no difference between a session cookie and any other cookie. It's just a cookie. So there's no technical reason why all the cookies can't coexist as long as there are no name collisions.

From the web server's perspective, if the non-session cookies had a purpose, that purpose is likely still there when there is a session, so deleting them to use the session in its place would probably just make the code more complex. But this doesn't say if they will or won't do that.

So, another way to ask the question would be "Are the authors of the website going to be lazy and not bother deleting redundant cookies, or are they going to be fancy and merge them into the session and clean things up?"

Also consider the session cookie and the other cookies may all have different lifetimes, so it might not make sense to merge them anyway.

what is the difference between $_ENV , $_SESSION and $_COOKIE

All three are superglobal, that means any script in your application can access it, BUT
while $_SESSION and $_COOKIE are different (and private) for each user, the $_ENV superglobal is not specific to a user. The difference between $_SESSION and $_COOKIE is that $_COOKIE can live beyond the current user visit, while the session will end when the user leave your site (or close his browser).

You can find here more good information about session http://www.php.net/manual/en/intro.session.php

Relation between sessions and cookies

Cookie

A cookie is just a key-value pair that is stored in the user's browser. A cookie is sent to your browser as part of the HTTP response that contains the web page you requested.

When your browser receives a cookie, it stores it, and sends it back to the server with every subsequent request it makes on the same website.

Because cookies are part of the HTTP request and response headers, they are somewhat limited in size.

Typical information stored in cookies:

Session IDs (see below)
Tracking IDs (Google Analytics, etc.)
User preferences (preferred language or currency, etc.)

For larger, or sensitive data, you typically store values in the session. The cookie is only there to identify the proper session.

A cookie can be configured to only live until the browser window is closed, or have a configurable lifetime (1 week, 1 month, 1 year, whatever). If you visit the website again during this period, your browser will send the cookie with every request.

Session

A session is a set of data that is stored on the server, usually as key-value pairs. A session is assigned a pseudo-random, secret ID that is usually stored in the user's browser using a cookie, for example SESSID=abcdef123456789. The session ID typically matches the name of a file containing the session data on the server.

Sessions are usually short-lived, and automatically deleted if unused for some time (20 minutes or so).

Typical information stored in a session:

ID of the user currently logged in
Shopping cart
... anything you can think of, that can be safely deleted when the session expires

Example

Let's say I visit a website for the first time. The website detects that I didn't send a session cookie, so it creates a session for me. It creates a session file on the server, such as /tmp/sess_abcdef123456789.

Then it sends a cookie header with the HTTP response that contains the web page:

HTTP/1.1 200 OK
Set-Cookie: SESSID=abcdef123456789

My browser stores this cookie. If I visit another page on the same server, my browser will send this cookie with the request:

GET /cart HTTP/1.1
Cookie: SESSID=abcdef123456789

When receiving the second request, the server can check if there's a session file with this ID, and use it to retrieve the session data.

Your web programming language will offer support for sessions, and should handle most of this complexity for you. You can usually directly use the session array/object, which will be already populated with the session data specific to the user visiting your website, and will be automatically saved if you update the session data; this should be totally transparent to you.

Security

When logging in a user to your website, always store the user ID in the session. Never trust a user ID stored in a cookie to load user data.

It's very easy to forge a cookie. If you were to load user information based on a user ID stored in a cookie, it would be easy to change the user ID in this cookie to gain access to any user's account on your website.

On the other hand, if you store the user ID in the session, which is assigned a pseudo-random session ID, it will be hard for an attacker to guess the session ID that is currently assigned to the user.

Differences between cookies and sessions?

Sessions are server-side files that contain user information, while Cookies are client-side files that contain user information. Sessions have a unique identifier that maps them to specific users. This identifier can be passed in the URL or saved into a session cookie.

Most modern sites use the second approach, saving the identifier in a Cookie instead of passing it in a URL (which poses a security risk). You are probably using this approach without knowing it, and by deleting the cookies you effectively erase their matching sessions as you remove the unique session identifier contained in the cookies.