Indications of use of cookies?

Asked

Viewed 630 times

3

What would be the indication to use cookies?

They would be a IsolateStorage web development, but so far I could not find an application for them, in a social media project I am working I used them only once to remember user login.

I do not have much confidence in this storage method, as they expire, are deleted, etc. In my personal opinion I prefer to use databases to record everything possible.

What classic examples of cookies applications could you give me? Where they really make a difference, and how to use them together with database (perhaps so as not to always have to access the database)

  • 1

    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).

  • 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.

  • 1

    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.

3 answers

7


What would be the indication to use cookies?

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

See, when we think about what this solves, we should be careful not to just look at what people do.

Let’s look at some use cases:

  • Login: makes sense because you want to authenticate the user on each request.
  • Security tokens: some implementations may use cookies to manage attack protection tokens XSRF. These tokens are generated by the server when opening a form and checked when the form is submitted.
  • User preferences:
    • Persistent: better to write to a database and bring to the page in some way, maybe as attributes.
    • Transients: disposable settings can use local Storage or Session Storage, unless you want to support old 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 answer. However, due to the various limitations, it is generally not a good idea to use cookies but some Storage already mentioned.
  • Temporary storage (cache): Some applications may use cookies to optimize the system, thus avoiding consulting data on the server at all times. However, the experience (mine and several people) is that the gain is minimal compared to the problems that this can generate for both usability and maintenance. A good implementation using some Storage can still help, but with various side effects like any cache, such as determining the right expiration time.

Cookies are not local data

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

This means that that wonderful idea of saving some data locally in cookies and thus avoid loading from the server is actually a backfire, because the data is sent to the server again in each request.

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

Considerations

Note that I didn’t even get into the question of how to manage the values, synchronize them with the server, how to handle 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.

5

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.

  • Would its real utility be for storing disposable data? Like data filled in inputs, custom styles.. Data that does not affect the basic functioning of the system? I thought that it had more important role, being able to decrease the number of accesses to the database leaving the system faster.

  • 1

    That’s right, he’s just a helper. You can even do this. He’d be using it as a browser cache. But if way to do this it is better to use Local Storage. It allows larger data and has a little more control on access. Besides what it’s made to last a little longer. It can be used for something that’s not so temporary, but don’t work with that idea. It is permanent until the user decides it is no longer. And the decision may come for something beyond his control, after all hardware, software and virus failures are there to "help".

2

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

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

About recording EVERYTHING in the database I think is unnecessary, a legal way to store temporary or permanent data (until the user cleans the local storage) introduced in HTML5 is to localStorage a cookie with steroids.

  • When I referred to "everything" I meant relevant and permanent data such as publications, comments, ratings and notifications. It is that the biggest doubt was what the cookies really serve, I thought it had a greater utility for the agility of the system, but this only happens as you mentioned right? When have sheets of styles for each user, etc, things irrelevant to the functioning of the system

  • 1

    I also agree with you, cookies should not contain data that can be compromised but data that if stolen will not affect system security.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.