Store ID in Cookie

Your site is becoming more popular, attendance records are beating weekly. You connect caching, understand the nuances of settings, optimize. But there comes a time when a single server is no longer enough, and the transition to the world's coolest piece of hardware does not find a complete understanding of the authorities. Oh yeah, you store the user ID in the PHP Session in a file, and it seems to be already mentally ready to put everything into the database, as the Internet recommends ... But something stops you.

Doubts!

Doubts about the feasibility of using the database for storing Sessions. Sessions in which only a couple of elements are the user ID and its role. And even at all - only the admin ID. You are haunted by the overhead of the network, new entities and the CAP-theorem. Every night you are pursued by the same nightmare - do not forget the letter B in the word Memcached ... That's it, let's consider the alternative - storing the client ID on his side, in Cookies.

So, setting the problem. So that

• Scalable
• Safely
• Quickly
• Simply

The author respects brevity and quite loosely applies the principle “Order and disorder is a matter of quantity.”

Decision

We select two variables in Cooks - one will store the public key, the other data. In the program code, we write a meaningless line of text, this will be our secret key. At initialization, we generate Initialization Vector - our public key. Data is written and read through symmetric encryption, using both of these keys. Do not forget about serialization. It will allow you to store data of different types. Profit You just got one step closer to Shared-nothing architecture.
')

Advantages and disadvantages

With scaling, everything is in order here - it is limited only by filtering Cook on the client side. Passing a pair through a request solves this problem. Thus, any random server from your pool will be able to correctly process the request, and the traffic balancer may become blunt to the network level of the model itself. The problem of periodically replacing the secret key is solved by the presence of two keys in the program. We try them in order.

Now we will improve protection. Cook's life time will be equal to 0. Then closing the browser will result in the regeneration of the public key the next time. To complicate the decryption, apply the "long" algorithm with a key of 256 bits. Next we tie the public key to the client's IP. For example, for md5 and MCRYPT_RIJNDAEL_256 complement each other perfectly:

$secret = md5(md5('My secret key') . md5($_SERVER['REMOTE_ADDR'])); 

Against creating a base for cryptanalysis, use the sleep command on every failed login attempt. Security officers can replace with die and block IP along with the account. Send a helicopter ...

Symmetric encryption is faster than networking. You are a heretic if you jerk the base, even local, even in RAM, even with a permanent connection or through a socket, with each click, when you can not do it. “Hello,% ID%” we can show immediately, without overhead.

Working with cookies in an application is more difficult than with a session. Especially if the latter is used as a mini-database, and output to the screen in different places of the program. We know that this is a bad practice, the dark past will complicate your path to a brighter future. So let the popularity of your service will become a motivator for refactoring! After all, your customers need you, and you need them. It's definitely easier with MVC frameworks.

Need more code!

The class for Zend Framework 1.x that implements Auth Cookie Storage is here . Even if you do not use ZF on high loads (hmm, the author is sure of this for some reason), then a couple of hundred lines of code with comments are sufficient for a Jedi medium uh-wizard to understand and play the principle in your favorite framework or session_set_save_handler .

Tuesday. The author will be grateful for any errors found anywhere.