Session variables and cookies seem very similar to me. I understand the technical differences, but how do you decide when to use one vs. the other?
相关问题
- Angular RxJS mergeMap types
- Google Apps Script: testing doPost() with cURL
- How to instantiate Http service in main.ts manuall
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- Multiple Django sites on the same domain - CSRF fa
相关文章
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- Is a unicode user agent legal inside an HTTP heade
- git: retry if http request failed
- fetch: Getting cookies from fetch response
- Flutter - http.get fails on macos build target: Co
- How do I send cookies with request when testing Fl
- Is ![removed] reliable?
- C# HttpClient.SendAsync always returns 404 but URL
Most of the time, session state is persisted using cookies. So it's not really a question of one or the other, but how to use them together.
Using your framework's session infrastructure may make things easier, but tracking state manually with cookies usually gives you finer grained control. The correct solution depends on what you're trying to accomplish.
Sessions and cookies are not the same at all. Cookies are client side. Sessions are server side. Sessions often (but not necessarily) use cookies to correlate one request with another from the same user to identify that they belong to the same session.
A session is an artificial concept, and HTTP doesn't have that notion. It is created by web servers to help web developers carry information across requests, like user account information, shopping carts, form data, etc. A cookie is carried by standard HTTP headers.
The information you store in a session vs. a cookie is up to you. Typically you put stuff in cookies that you want to persist across sessions after the user closes his/her browser. Maybe remembering authentication tokens to implement "remember me" functionality, or past user activity to personalise his/her experience. Keep this information small and "referential", i.e. it could be just IDs that refer to richer information you store sever side. Remember that what is client side is more vulnerable to malware, so don't store passwords or sensitive information.
Finally, there is also local storage, which you did not mention. This is also client side, but arguably a bit less susceptible to cross-site scripting hacks since, unlike cookies data, it is not automatically sent in the headers.
Sessions are stored on the server. If you store something in a cookie, the user's browser sends that information with every request, potentially slowing down your site from the user's perspective. I try to avoid using cookies when I can.
Cookies are sent to the server on every request, so if you plan to store a fair amount of data, store it in a session.
Otherwise, if you are storing small amounts of data, a cookie will be fine.
Any sensitive data should be stored in a session, as cookies are not 100% secure. An advantage of cookies is that you can save memory on your server that would normally be storing session data.
Cookies are client-side, and sessions are server-side.
Use cookies for small pieces of data that you can trust the user with (like font settings, site theme, etc.) and for opaque IDs for server-side data (such as session ID). Expect that these data can be lost at any time and they can not be trusted (i.e. need to be sanitized).
Use session data for bigger data chunks (for many systems can store objects, data structures, etc.) and ones you have to trust - like authorization status, etc. In general, use session data for storing larger state data.
You can store things like authorization status in cookies too, if it's needed for GUI, caching, etc. - but never trust it and never rely on it being present. Cookies are easy to delete and easy to fake. Session data is much harder to fake, since your application controls it.