3

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

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
eomeroff
  • 9,599
  • 30
  • 97
  • 138
  • 1
    Please give more details on your environment, including language and how you're storing session data. – Matthew Flaschen Feb 02 '10 at 01:05
  • it is ASP.NET technology, I am having issues in operations with tepm user that I keep in session and a bit complex document upload functionality where I keep whole document in session until they get stored in DB, as this is team project we are having architectural discussions.. – eomeroff Feb 02 '10 at 01:13
  • Why did someone dislike the question?? – eomeroff Feb 02 '10 at 01:20
  • 1
    Don't store the complete text of *In Search of Lost Time* by Marcel Proust. Last time I tried that, the server went into sleep mode and it took 3 weeks to wake it up. – Aaronaught Feb 02 '10 at 03:28

9 Answers9

7

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.
BobMcGee
  • 19,824
  • 10
  • 45
  • 57
  • +1 for reminder of how dangerous badgers can be inside a web server –  Feb 02 '10 at 02:02
  • 1
    @yoda: you only need to get hit by a single badger injection exploit before you learn to sanitize and thoroughly pulverize your input. Also to carry a heavy flashlight when investigating usual noises in the server room. – BobMcGee Feb 02 '10 at 02:17
  • Badgers? Badgers?!? We don't need no stinkin' badgers! – Jesse Weigert Feb 02 '10 at 02:42
4

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.

Jacob
  • 77,566
  • 24
  • 149
  • 228
  • User sessions work with web farm, but not app sessions. – Chris O Feb 02 '10 at 03:03
  • I agree with Jacob. If your requests are stateless, it makes the site much easier to test. – 0sumgain Feb 02 '10 at 03:18
  • 2
    @Chris, even for user sessions, you cannot rely on them 100%. At any point, a node in the farm could be removed, thereby wiping out any in-memory sessions stored there. You can, of course, store sessions in a database, but you'd might as well use real tables with a defined schema at that point. – Jacob Feb 02 '10 at 03:25
  • thanks for the info on the web farms, very good to know. – Chris O Feb 02 '10 at 15:12
2

COM or complex objects.

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

Community
  • 1
  • 1
Rubens Farias
  • 57,174
  • 8
  • 131
  • 162
2

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.

alex
  • 479,566
  • 201
  • 878
  • 984
1

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.

Chris Conway
  • 16,269
  • 23
  • 96
  • 113
1

I would not put the session inside the session also!

fastcodejava
  • 39,895
  • 28
  • 133
  • 186
0

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.

herzmeister
  • 11,101
  • 2
  • 41
  • 51
  • Multiple GB of data *might* pose a problem in this case. Especially if on a 32-bit webserver (theoretically possible). – BobMcGee Feb 02 '10 at 02:18
  • The 2nd paragraph is why I *always* use `` - I'll get an error as soon as I try and store a non-serializable object. – devstuff Feb 02 '10 at 03:16
0
  • 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.

Zhaph - Ben Duguid
  • 26,785
  • 5
  • 80
  • 117
0

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!

Ken
  • 372
  • 3
  • 9