Session data in Redis

In this article we’ll cover one of the most omnipresent mechanisms for authentication in web applications.

Internet users are used to login to the application once and then stay logged in. We’ll consider web application (HTTP protocol), but the general idea may apply to any stateless client-server architecture application.  From programmer perspective each and every request is independent, so we have no clue whether user is logged in or not.

The easiest solution would be to send username and password with every request, but it wouldn’t be convenient from the user perspective.

The idea that emerged in the Internet world for solving this problem is called session.  In this approach, each user gets a unique and impossible to guess token which will be his credential for later use. He or she may still not be logged in. The token is assigned at the very beginning of the first connection and later presented before sending in the heading of every connection. If the user will decide to log in (by sending username and password to our login form) then the server may remember the authorization, so the user won’t have to log in again. Even if the user will change the password, this token may stay valid, since the token is usually store separately from the user database.

This token can be also used for tracking activity of potentially anonymous users. Web browser establishes and later sends this token without any information for the user.

Cookie is a small piece of data send from the server to web browser and later used by the web browser to identify itself within connections to a particular domain.

Cookie may have additional attributes. Here are some of them:

• Secure  – cookie will be used only for https connections
• Http only – cookie cannot be used by JS async requests (preventing for cross site-scripting)
• SameSite Strict – cookie will be used only for exactly same domain as it was established for (not for subdomains).

Note: cookies are stored in the web browser, so using two different browsers on the same OS and physical machine results in two separate sessions.

We can track below what web browser and server are sending.

Phase 1:

• web browser is sending an HTTP request for www.asl24.pl site
• server responds and sets the cookie named MYSID with value abc123 (Set-cookie: MYSID=abc123 )

Phase 2:

• web browser sends a HTTP request for login.php site, but this times it attaches the information about a cookie name and value assigned to the domain asl24.pl
• server already knows that it’s the same web browser as it was in Phase 1, and presents the login form from login.php site.

Phase 3:

• in this phase the user fills the form and sends it via HTTP POST request, again sending in the heading information about the cookie established before.
• (assuming the username and password were OK)
• from now on server will that the user with cookie MYSID=abc123 is properly logged in.

We should notice that the cookie information may be send with every HTTP request. This usually means that the cookie will be search quite often. That’s why we’ll need a fast key-value storage for this.

Standard SQL database will be to slow for simple key-value storage and here’s where Redis comes with help. Redis is really fast key-value storage server and can process approx 10k requests per second with just one core of CPU.  This is the main reason why we decided to use Redis.

Note:

• The default mechanism for sessions in PHP keeps the cookies/session information in the filesystem – each cookie as a separate file. Considering a website with 100k sessions, we would have a folder with 100k files.

Session example in PHP

You can download the presented files functions.php, index.php, login.php.