What would be the way to use cookies?

Any information you want to be sent back to the server on the next request, regardless of the type of request.

See, when we think of what this does, we must be careful not to simply look at what people do.

Let's look at some use cases:

• Login : It makes sense because you want to authenticate the user on each request.
• Security Tokens : Some implementations can use cookies to manage attack protection tokens XSRF . These tokens are generated by the server when you open a form and are checked when the form is submitted.
• User Preferences :
  • Persistent: better write to a database and bring the page in some way, perhaps as attributes.
  • Transients: Disposable configurations can use local storage or session storage , unless you want to support legacy browsers.
• Intermediate storage : Some AJAX applications may use some mechanism to save data that is not yet ready to go to the server. For example, Stack Overflow saves the draft of your response. However, due to various limitations, it is generally not a good idea to use cookies, but rather some storage mentioned above.
• Temporary storage ) : Some applications can use cookies to optimize the system, thus avoiding querying data on the server at all times. However, the experience (mine and many people) is that the gain is minimal compared to the problems this can generate for both usability and maintenance. A good implementation using some storage might still help, but with several side effects like every cache, such as determining the right moment of expiration.

Cookies are not local data

Something important is that cookies generate overhead on each request to the server.

That means that the wonderful idea of saving some data locally in cookies and thus avoiding loading from the server actually backfires, since the data is sent back to the server on each request.

If you have 1KB of information in cookies, each time the user clicks a link, that 1KB will be transmitted in the request header and processed by the server.

Considerations

Note that I did not even get into the question of how to manage the values, synchronize them with the server, how to deal with data when they disappear, and so on.

These are consequences of the proposed model. The important point is to understand that the scope of cookies is different from other more specific solutions.

If you do not see use for it, maybe it's fine. It is common for programmer to find a solution and then to look for a problem to apply it. This does not usually work out.

• One of the biggest uses is the Identify the user . Several techniques can be used to do this. I'd say it's the only one worth using.

  This ID can be a unique code where you will associate records with what it does in your database on the server. It's quite simple. It's just a bookmark.

  This technique is used to generate access statistics and track what the user is doing. This can be considered an invasion of privacy, although few people worry about it. Several sites warn that they are doing this and are using third-party tools that use this technique. This may prevent prosecution in more litigious countries.

• cookie can be used for session control . And it's a user identification specialization that, in theory, will expire soon. The cookie is great for creating a status impression while browsing.

  Normally the web is used to access pages in isolation. To organize each access of the same browser as a continuation of something already done, you create session, keeping the state on the server. To know if the new communication between the browser and the server comes from the same source and should be considered as being of the same session, you have to identify the user. The cookie is meant for this. Some people consider this the only possibility of using cookie today, for good reason.

  This can be used to give more security by providing access tokens to ensure that the session is not misused.

• Another way they use is to save some settings as the user prefers to access the site. Of course it can not be anything too sophisticated and important. Consider it temporary. With the advent of other techniques, this has been pushed aside, even by intrinsic inefficiency. Consider a legacy technique.

  You can store this in the browser database. This is Local Storage. It is preferable for larger data to avoid transporting unnecessary data between browser and HTTP server communication.

• Other uses such as cache are even used, but not recommended.

Local database

The local database has its advantages there, but it does not solve everything and can not always be used. Like cookies, it can only be used if the user accepts it and can manipulate or delete the time that he or she understands. There is no escape from it. Of course, the browser database fits more data, allows more control, but apart from that and the data is not used in direct communication, see it as a super-cookie , no more than this .

Do you want to store user information permanently? Do it on the server. Do you always want to identify who is the user of that browser to get their information from the server? You have no warranties. The cookie is for this, if it is there the way you put it. You have to have other ways to identify the spontaneous user, for example.

Do you want someone who does not know you to give her access to your computer and you have complete control over it? It is not viable.

Expiration

The expiration is controlled by you, until the user wants to interfere with it. There are own techniques to determine when it expires. It is common to use something that expires soon to keep the session active. Obviously you have to go to extend the expiration. There are those who wish to keep the session active for a long time.

This is a way to prevent the person from having to make a new login . This is practical but not very safe. You can even do this but know the risk and take some precautions to avoid catching easily. Anything that requires a little more security than the trivial should not use this technique.

Conclusion

You think right when you think it's not a reliable, robust mechanism.

It should not be abused, and it may not be the only way to get what you want. But there's no escape from it in some situations.

Plan the use for something simple and ephemeral.

Cookies are usually used to save preferences (style sheet, usage data, number of hits, frequency, etc.).

At the beginning of Orkut only with the user's cookie you could access the account without even having the password this is a security failure, the cookie should NEVER be used as the only way to identify the user.

On writing ALL in the database I believe is unnecessary, a legal way of storing temporary or permanent data (until the user clears local storage) introduced in HTML5 is the localStorage a cookie with steroids.