What kind of data should never go into session? [closed]

开发者_运维知识库 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

What kinds of data should never be kept in a session?

---

I really wish it was clearer what kind of session you mean. Depending on the answer, I can come up with a couple:

• Passwords of any sort
• Large amounts of data, especially 4 GB+ on a 32-bit OS (guaranteed out of memory if it has to be loaded into RAM)
• Executable code
• Raw SQL
• Swear words
• Things likely to get government agencies angry ("Free Tibet" in China, threats to the president in the US)
• Your bank account PIN or credit card number
• A rabid badger. Actually, ANY kind of badger.

---

If possible, store nothing in the Session. It is an unreliable way to maintain state, especially if you need to move to a web farm. Also, I believe it encourages poor design. HTTP is stateless, and web sites should be designed in a way where you assume that for any request, you could be starting over from scratch.

---

COM or complex objects.

This link can also be useful: ASP.NET 2.0 Performance Inspection Questions - Session State

---

This answer is for PHP Sessions.

If you mean $_SESSION, well it is stored on the hard drive, so it is not immediately available in anything like the cookies.

However, on a shared host, it can sometimes be trivial to access session files from other websites.

I would not store anything in the session you wouldn't want anyone else on your shared host to see.

---

This can be a pretty subjective question. Anything that's serializable can be stored in session, technically. But there are definitely scenarios where you don't want to add things to session. Complex objects, objects that have large collections as properties, etc. All these things are serialized into byte arrays and kept in memory (for InProc Session State) and then deserialized when needed in code again. The more complex the object, the more resource intensive it can get to go back and forth.

Depending on how many users you have, you may wish to limit the number of items that go into session and perhaps use ViewState or other means of persistence. If it's truly something meant for multiple pages, then it's probably a good candidate for session. If it's only used in a page or two, then ViewState, QueryString, etc. may be better.

---

I would not put the session inside the session also!

---

You can store anything in Session as long as you keep the SessionMode="InProc" in the web.config. This stores any session data in the web server's memory in a user specific context.

However, if you want to scale up one day and run your web app in a farm, you will have to use another SessionMode. Then you can't any longer store objects of complex types that are not serializable (unfortunately, dictionaries are a common candidate) and you will have to change your design.

---

• DataSets: Serialising a dataset to store in session can take up an order of magnitude more memory than the dataset itself (i.e. a 1MB dataset can need 20MB to serialise/deserialise, and it does that on every request).
• Controls: Storing controls (and their collections) in session means that ASP.NET can't clean them up properly at the end of the page request, leading to memory leaks.

See Tess Ferrandez's blog for other examples of things you should never put in session, along with reasons why.

---

Stock tips, pirated CDs, full-length movies (except "Clerks", that movie was awesome), analog information, ...

This question seems kind of vague -- I can think of countless kinds of information that shouldn't be stored in the session!