ID stored in the Cookie

Your website more popular, the attendance records I weekly. You connect caching, understand the nuances of the settings optimizing. But there comes a time when one server is not enough, and the transition to the cool in the world thing is not the understanding of his superiors. Oh yeah, the user ID You store in the PHP Session file, and it seems to be already morally ready to put everything into a database, as recommended by the Internet... But something stops You.

Doubt!

Doubts about the feasibility of using database to store Sessions. Sessions, which are only a couple of elements- the user ID Yes his role. If not — only the ID of the administrator. You do not give rest overhead on the network, a new entity and the CAP-theorem. Every night You are haunted by the same nightmare – not to forget the letter B in the word Memcached... All, let's consider the alternative — storing the ID of the client on his side, in a Cookie.

so, the statement of the problem. To

the

the
• Scalable
the
• Safe
the
• Fast
the
• Just

The author respects the short and very loosely applies the principle of matter of quantity."

Solution

The Cookie allocated in two variables, one to store the public key, the other data. In program code, append a nonsense string of text, it will be our secret key. During the initialization of the generated Initialization Vector is our public key. The data write and read using symmetric encryption, using both of these keys. Don't forget the serialization. It will allow you to store data of different types. Profit. You just became one step closer to Shared-nothing architecture.

Pros and cons

Scaling everything is in order, it is only limited by the cook filtering on the client side. Vapor transfer through the query solves this problem. Thus, any random server out of your pool will be able to correctly process the request and the balancer traffic can be dumbed down to the network layer of the model. The problem is periodic replacement of the secret key is solved by the presence of two keys in the program. Try them in order.

Now perfect protection. The life time of the cook will make is 0. Then closing the browser will lead to a regeneration of the public key the next time. To complicate decryption applies the "long" algorithm with a key of 256 bits. Next, bind the public key to the client IP. For example, for md5 and MCRYPT_RIJNDAEL_256 complement each other:

the

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

Against the establishment of bases for cryptanalysis use the sleep command for each unsuccessful login attempt. Bezopasniki can replace die and banning the IP address along with the account. Send a chopper...

Symmetric encryption is faster networking. You are a heretic if you pull the base, even local, even in memory, even with a permanent connection or through a socket every time you click, when you don't have to do. "Hello, %ID%" we can show immediately, with no overhead.

Working with Cookies in your app is more complicated than with a session. Especially if the latter is used as a mini database, and display in various places in the program. We know that it is bad practice dark past will complicate Your way to a brighter future. So let the popularity of Your service will be a motivator for refactoring! After all, You need Your customers, and they need You. Definitely, MVC frameworks, everything is easier.

Need more code!

Class for Zend Framework 1.x, which implements the Auth Cookie Storage — here. Even if You are not using ZF at high loads (hmm, the author is somehow convinced of this), a couple of hundred lines of code with comments sufficient average Jedi um hands for the understanding and reproduction of the principle in your favorite framework, or session_set_save_handler.

Tuesday. The author is grateful for any found anywhere errors.

Article based on information from habrahabr.ru