The Classic ASP Session object stores per-visitor values on the server between requests. Typical uses include a signed-in user ID, a short-lived preference, or workflow state that must survive navigation from one ASP page to another.
Session state is different from query strings and form fields because those values travel with individual requests. The server associates session state with a session identifier maintained by ASP.
Response.Write Session.SessionIDTreat the session identifier as implementation detail. Do not print it on production pages or use it as a public account identifier.
Keep only user-specific, short-lived state in Session. Site-wide announcements and other shared information belong in application configuration, a database, cache, or another shared store.
Session values live on the server, so large objects or excessive per-user state consume memory. Store compact values such as IDs rather than whole recordsets or large data structures. Classic ASP session state is enabled by default in IIS and the default timeout is 20 minutes unless the server configuration or application changes it.
Server-side storage does not make every value automatically safe. Do not store a user's plaintext password in Session. Use HTTPS, keep authentication state minimal, validate authorization on protected pages, and avoid exposing the session identifier in URLs or page output.
Author & Instructor at plus2net
I write and maintain practical tutorials on Python, PHP, SQL, JavaScript, HTML, jQuery, and web development at plus2net. The tutorials focus on clear explanations, working examples, and code that readers can test and adapt while learning.