If you don’t see use for it maybe it’s good. It’s common for programmers to find a solution and then look for a problem to apply it. This doesn’t usually work out.
One of the greatest uses is precisely the cited, identify the user. Various techniques can be used to do this, I would even say that it is the only one worth using.
This identification can be a unique code where you will associate records of what it does in your database on the server. It’s something very simple, it’s just a marker.
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 care about it (this is serious now with legislation on the subject). Several websites warn that they are doing this and are using third party tools that use this technique. This can avoid lawsuits in more contentious countries.
The cookie can be used to session control. And it is a specialization of user identification that, in theory, will soon expire. The cookie is great for creating a status impression while browsing.
Usually the web is used to access pages in isolation. To organize each access of the same browser as if it were 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 must be considered to be from the same session you have to identify the user. The cookie was made for this. Some people consider this the only possibility of using cookie currently, for good reason.
This can be used to give more security providing tokens access to ensure that the session is not misused.
Another way they use is to save some settings of how the user prefers to access the site. Of course it can’t be anything too sophisticated and important. Consider it as something temporary. With the advent of other techniques this has been set aside, even by intrinsic inefficiency. Consider a legacy technique.
You can store this in the browser database, the Local Storage. It is preferable for larger data to avoid carrying unnecessary data between browser and HTTP server communication.
Other uses like cache are even used, but not recommended.
Local database
The local database has its advantages there, but it does not solve everything and cannot always be used. As well as the cookies, it can only be used if the user accepts and he can manipulate or delete the time as he wishes. There is no escape from this. Of course the browser database fits more data, allows more control, but other than that and the data is not used in direct communication, see it as a super-cookie, no more than this.
Permanent data
Want to store user information permanently? Do it on the server.
Always want to identify the user of that browser to get his information from the server? No guarantees.
The cookie serves this, if it is there the way you put it. There have to be other ways to identify the user (login spontaneous, for example).
Do you want someone who doesn’t know you to give you access to her computer and you have complete control over it? It’s not feasible.
Expiration
The expiration is controlled by you until the user wants to interfere with it. There are techniques in place to determine when it expires. It is common to use something that expires soon to keep the session active and obviously has to go extending the expiration. There are those who wish to keep the session active for a long period.
This is one way to prevent the person from being forced to make a new login. This is practical but not very safe. You can even do this but knowing the risk and taking some precautions to avoid catching easily. Anything that requires a little more security than trivial should not use this technique.
Completion
Think right when you think it’s not a reliable and robust mechanism.
He should not be abused, and may not be the only way to get what he wants. But there is no way to get away from him in some situations.
Plan the use for something simple and ephemeral.
I think the question is a bit wide, but it follows a personal practice: I only use cookies to maintain the user’s session, that’s all. I can barely leave someone else for statistical purposes, but that’s it. And even so, in the case of the session, you need to manage the bug (the cookie) right, so that it does not expire in the middle of the use (as with many application that only arrow the cookie and drop there).
– Bacco
Holding the session would keep the user logged in when checked to keep logged in? In case I only used to leave user and password in login inputs.
– Leonardo
Holding the session is vc give a unique identifier to the user, and through this identifier you see on the server whether the user is logged in or not, who he is, etc. In this case, the term session refers to the fact that you discard the data associated with this cookie after the user has moved, or after an inactivity time.
– Bacco