How Session Works

What are cookies and sessions, and how do they relate to each other?

Let's go through this:

Cookies and sessions are both ways to preserve the application's state between different requests the browser makes. It's thanks to them that, for instance, you don't need to log in every time you request a page on StackOverflow.

Cookies

Cookies are small bits of data, (maximum of 4KB long), which hold data in a key=value pairs:

name=value; name2=value2

These are set either by JavaScript, or via the server using an HTTP header.

Cookies have an expiry datetime set, example using HTTP headers:

Set-Cookie: name2=value2; Expires=Wed, 19 Jun 2021 10:18:14 GMT

Which would cause the browser to set a cookie named name2 with a value of value2, which would expire in about 9 years.

Cookies are considered highly insecure because the user can easily manipulate their content. That's why you should always validate cookie data. Don't assume what you get from a cookie is necessarily what you expect.

Cookies are usually used to preserve login state, where a username and a special hash are sent from the browser, and the server checks them against the database to approve access.

Cookies are also often used in sessions creation.

Sessions

Sessions are slightly different. Each user gets a session ID, which is sent back to the server for validation either by cookie or by GET variable.

Sessions are usually short-lived, which makes them ideal in saving temporary state between applications. Sessions also expire once the user closes the browser.

Sessions are considered more secure than cookies because the variables themselves are kept on the server. Here's how it works:

1. Server opens a session (sets a cookie via HTTP header)
2. Server sets a session variable.
3. Client changes page
4. Client sends all cookies, along with the session ID from step 1.
5. Server reads session ID from cookie.
6. Server matches session ID from a list in a database (or memory etc).
7. Server finds a match, reads variables which are now available on $_SESSION superglobal.

If PHP does not find a match, it will start a new session, and repeat the steps from 1-7.

You can store sensitive information on a session because it is kept on the server, but be aware that the session ID can still be stolen if the user, let's say, logged in over an insecure WiFi. (An attacker can sniff the cookies, and set it as its own, he won't see the variables themselves, but the server will identify the attacker as the user).

---

That's the gist of it. You can learn more on the PHP manual on both subjects.

How Session Works?

Sessions are made up of two components, a client-side session ID and server-side session data. Clients can send a session ID to the server as a URL param, cookie, or even HTTP headers.
The server then uses this session ID to find the appropriate session data to return to the client.

You can tweak session behavior via the various session_ functions.

What are sessions? How do they work?

Because HTTP is stateless, in order to associate a request to any other request, you need a way to store user data between HTTP requests.

Cookies or URL parameters ( for ex. like http://example.com/myPage?asd=lol&boo=no ) are both suitable ways to transport data between 2 or more request.
However they are not good in case you don't want that data to be readable/editable on client side.

The solution is to store that data server side, give it an "id", and let the client only know (and pass back at every http request) that id. There you go, sessions implemented. Or you can use the client as a convenient remote storage, but you would encrypt the data and keep the secret server-side.

Of course there are other aspects to consider, like you don't want people to hijack other's sessions, you want sessions to not last forever but to expire, and so on.

In your specific example, the user id (could be username or another unique ID in your user database) is stored in the session data, server-side, after successful identification. Then for every HTTP request you get from the client, the session id (given by the client) will point you to the correct session data (stored by the server) that contains the authenticated user id - that way your code will know what user it is talking to.

How do PHP sessions work? (not how are they used?)

In the general situation :

• the session id is sent to the user when his session is created.
• it is stored in a cookie (called, by default, PHPSESSID)
• that cookie is sent by the browser to the server with each request
• the server (PHP) uses that cookie, containing the session_id, to know which file corresponds to that user.

The data in the sessions files is the content of $_SESSION, serialized (ie, represented as a string -- with a function such as serialize) ; and is un-serialized when the file is loaded by PHP, to populate the $_SESSION array.

Sometimes, the session id is not stored in a cookie, but sent in URLs, too -- but that's quite rare, nowadays.

For more informations, you can take a look at the Session Handling section of the manual, that gives some useful informations.

For instance, there is a page about Passing the Session ID, which explains how the session id is passed from page to page, using a cookie, or in URLs -- and which configuration options affect this.

How session works in Rails

session is not a global hash. It's a method that returns a new hash in the context of each request. How that hash is created depends on the underlying session store.

Let's take a look at 2 typical session stores.

Encrypted cookie store

This is the default session store of Rails applications. Rails serializes then encrypts the whole session hashes into cookies, and stores those cookies on the clients (e.g. browsers). Each time a request hits Rails app, Rails decrypts then deserializes that session cookie to a hash. That hash is what the method session returns.

Redis session store

This session store is not shipped with Rails. It's a separate gem.

With this session store, Rails serializes the session, gives it an ID (called session ID), and stores the ID-hash pair into Redis. Rails then set the session ID to cookie and send that cookie to the client. Each time a request hits Rails app, Rails retrieves the session ID from the cookie, gets the serialized session associated with that session ID from Redis, and deserializes that into a hash. That hash is what the method session returns.

How Session Works?

Sessions are made up of two components, a client-side session ID and server-side session data. Clients can send a session ID to the server as a URL param, cookie, or even HTTP headers.
The server then uses this session ID to find the appropriate session data to return to the client.

You can tweak session behavior via the various session_ functions.

How does Flask Sessions work?

The default session is implemented using secure cookies. Cookies are persisted by the client's browser, Flask doesn't do anything in that regard. Each client has a unique session cookie, which it sends to the Flask server with each request.

The cookie is secure not encrypted, it does not prevent anyone with the cookie from viewing the data, only from modifying it. Flask signs the data with the app's secret key when sending it, and unsigns it with the same key when reading it.

Flask does not add anything to the session. There is no session id, the browser just sends the session cookie during each request, and Flask reads it.

You can write your own session interface to change how the session works. See extensions such as Flask-Session

---

Related Topics