ASP.NET Web Forms

Session State Access in Pageless ASP.NET Web Forms Architecture (Using Framework Built-in Session Management)

Updated:

Important Note: This article best suit as an alternative. In Pageless Web Forms Architecture, the more reliable and predictable behavior of session management, one should implement self-manage sessions, please follow the following article:

Article Title (Primary Method): Session Management in Pageless ASP.NET Web Forms (Self-Manage)

How to access the IIS built-in session state in ASP.NET Web Forms without using .aspx pages, master pages, or the page lifecycle — by intercepting requests at Application_PostAcquireRequestState in Global.asax.cs.

What This Article Covers

ASP.NET Web Forms provides built-in session state through the SessionStateModule, an IIS managed module that automatically loads and saves per-user session data on every request. In conventional Web Forms, session state is accessed inside .aspx code-behind classes via Session["key"] or HttpContext.Current.Session["key"], and the page lifecycle ensures that session data is available by the time Page_Load executes.

In Pageless Web Forms Architecture, there are no .aspx pages. There is no page lifecycle. Requests are intercepted at Global.asax.cs pipeline events and responses are written directly to HttpContext.Current.Response. The question this raises is: can you still use the built-in session state without the page lifecycle?

The answer is yes. The SessionStateModule and the page lifecycle are independent components of the ASP.NET pipeline. Session state is loaded by a module at the AcquireRequestState stage — well before any page handler executes. By intercepting at Application_PostAcquireRequestState, you get full session access with zero page lifecycle overhead.

This article explains how it works, why it works, and how to build a complete session-aware authentication system on top of it.

Part 1: Understanding the Pipeline

The ASP.NET HTTP Pipeline Event Sequence

When IIS receives an HTTP request for an ASP.NET application, the request passes through a fixed sequence of pipeline events. Each event is a hook where modules and application code can execute. Understanding this sequence is essential to understanding where session state becomes available.

Here is the complete pipeline in order:

 1. BeginRequest
 2. AuthenticateRequest
 3. PostAuthenticateRequest
 4. AuthorizeRequest
 5. PostAuthorizeRequest
 6. ResolveRequestCache
 7. PostResolveRequestCache
 8. MapRequestHandler
 9. PostMapRequestHandler
10. AcquireRequestState          ← SessionStateModule loads session here
11. PostAcquireRequestState      ← Session is now available
12. PreRequestHandlerExecute
13. [Handler Execution]          ← Page lifecycle runs here (if .aspx)
14. PostRequestHandlerExecute
15. ReleaseRequestState          ← SessionStateModule saves session here
16. PostReleaseRequestState
17. UpdateRequestCache
18. PostUpdateRequestCache
19. LogRequest
20. PostLogRequest
21. EndRequest
22. PreSendRequestHeaders
23. PreSendRequestContent

The critical events for Pageless Architecture are:

Event 1 — BeginRequest: The very first event. The HTTP request has been parsed by IIS. HttpContext.Current.Request is fully populated with headers, URL, query string, cookies, form data, and the request body stream. But HttpContext.Current.Session is null — the SessionStateModule has not yet executed. This is the interception point for stateless endpoints.

Event 10 — AcquireRequestState: The SessionStateModule reads the session ID from the request cookie (typically ASP.NET_SessionId), loads the session data from the configured session store (InProc memory, StateServer, or SQL Server), and populates HttpContext.Current.Session.

Event 11 — PostAcquireRequestState: Fires immediately after the session module finishes. HttpContext.Current.Session is now fully hydrated and available for reading and writing. This is the earliest point where session state can be accessed. The page handler has not yet been instantiated. No .aspx file has been loaded. No control tree exists. No ViewState has been processed.

Event 13 — Handler Execution: In conventional Web Forms, this is where the .aspx page handler runs the full page lifecycle: PreInit → Init → InitComplete → PreLoad → Load → LoadComplete → PreRender → SaveStateComplete → Render. In Pageless Architecture, this never executes because the response has already been completed at event 11.

Event 15 — ReleaseRequestState: The SessionStateModule saves any changes made to HttpContext.Current.Session back to the session store. This event fires even if you terminated the response early with CompleteRequest() — the session is still saved properly.

The Gap That Makes Pageless Architecture Possible

The key insight is the gap between events 11 and 13. At event 11 (PostAcquireRequestState), you have everything:

  • HttpContext.Current.Request — fully parsed HTTP request
  • HttpContext.Current.Response — ready for writing
  • HttpContext.Current.Session — fully loaded session data
  • HttpContext.Current.User — authenticated identity (if using Forms Authentication)
  • HttpContext.Current.Application — application-level state

But the page handler (event 13) has not run. No .aspx file has been touched. No System.Web.UI.Page object has been created. The entire Web Forms page lifecycle — all ten events from PreInit through Render — has not started and will not start.

You can write your complete response at event 11 and call CompleteRequest(). The pipeline skips directly to EndRequest (event 21), passing through ReleaseRequestState (event 15) on the way — which means the SessionStateModule still saves your session changes. Everything works. Nothing is lost.

Part 2: Basic Session Access

The Minimum Viable Example

Here is the simplest possible session-aware page handler intercepted at PostAcquireRequestState:

// In Global.asax.cs:

protected void Application_PostAcquireRequestState(object sender, EventArgs e)
{
    if (HttpContext.Current?.Session == null)
        return;  // Not a session-eligible request (e.g., static file)

    string path = Request.Path.ToLower().Trim().TrimEnd('/');

    switch (path)
    {
        case "/":
        case "/home":
            HandleHomeRequest();
            break;
        case "/dashboard":
            HandleDashboardRequest();
            break;
    }
}

static void HandleDashboardRequest()
{
    HttpResponse Response = HttpContext.Current.Response;

    // Read from the built-in session state
    string username = HttpContext.Current.Session["Username"] as string;

    if (string.IsNullOrEmpty(username))
    {
        // Not logged in — redirect to login page
        Response.Redirect("/login", true);
        return;
    }

    // Render a page with session-derived content
    Response.ContentType = "text/html";
    Response.Write($@"
<!DOCTYPE html>
<html lang='en'>
<head>
    <meta charset='utf-8'>
    <title>Dashboard</title>
</head>
<body>
    <h1>Welcome back, {HttpUtility.HtmlEncode(username)}</h1>
    <p>This page knows who you are because the SessionStateModule
       loaded your session data before this code executed.</p>
    <a href='/logout'>Logout</a>
</body>
</html>");

    try { Response.Flush(); } catch { }
    Response.SuppressContent = true;
    HttpContext.Current.ApplicationInstance.CompleteRequest();
}

This page reads from HttpContext.Current.Session["Username"] and renders personalized content — or redirects to login if the session is empty. The session was loaded by the SessionStateModule at event 10, automatically, with no code on our part. We just read from it at event 11.

Writing to the Session

Session state is read-write at PostAcquireRequestState. You can store values during a request and read them back on subsequent requests:

static void HandleLoginPostRequest()
{
    HttpRequest Request = HttpContext.Current.Request;
    HttpResponse Response = HttpContext.Current.Response;

    string username = (Request.Form["username"] ?? "").Trim();
    string password = Request.Form["password"] ?? "";

    // Validate credentials against database
    obUser user = ValidateCredentials(username, password);

    if (user == null)
    {
        Response.Redirect("/login?error=invalid", false);
        HttpContext.Current.ApplicationInstance.CompleteRequest();
        return;
    }

    // Write to the built-in session state
    HttpContext.Current.Session["UserId"] = user.Id;
    HttpContext.Current.Session["Username"] = user.Username;

    Response.Redirect("/dashboard", false);
    HttpContext.Current.ApplicationInstance.CompleteRequest();
}

When CompleteRequest() fires, the pipeline continues to ReleaseRequestState (event 15), where the SessionStateModule persists the session data. On the next request, the module reloads it at AcquireRequestState (event 10). The cycle is seamless — exactly the same as it would be in a conventional .aspx code-behind, but without the page lifecycle.

The Session Null Check

One important detail: not every request goes through the SessionStateModule. Requests for static files (.css, .js, .png, .jpg) may not have session state loaded, depending on IIS configuration. The runAllManagedModulesForAllRequests setting in web.config controls this:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
</system.webServer>

When set to true, all managed modules — including SessionStateModule — run for every request, including static files. When set to false (or absent), managed modules only run for requests mapped to managed handlers (.aspx, .ashx, etc.).

In a Pageless architecture, you typically set this to true because your routes don’t use file extensions — /profile, /dashboard, /forums — and IIS needs to know to run managed modules for these extensionless URLs. But you should still check for null before accessing session:

**Note: Important Steps**

protected void Application_PostAcquireRequestState(object sender, EventArgs e)
{
    // Guard: session may be null for static file requests
    if (HttpContext.Current?.Session == null)
        return;

    // ==== IMPORTANT ====
    // Safe to access session from here onwards
    AppSession.TryRestoreFromCookie();

    // ... routing logic
}

Session Configuration

The built-in session state requires no explicit configuration for the default InProc mode. The defaults are:

  • Mode: InProc (session data stored in web server memory)
  • Timeout: 20 minutes of inactivity
  • Cookie name: ASP.NET_SessionId
  • Cookieless: false (uses cookies by default)

These defaults are active with no <sessionState> element in web.config. For most single-server applications, this is sufficient. The session just works.

If you need to customize the session, add a <sessionState> element to web.config:

<system.web>
    <sessionState
        mode="InProc"
        timeout="30"
        cookieName="ASP.NET_SessionId"
        cookieless="false" />
</system.web>

For load-balanced or multi-server deployments, switch to StateServer or SQL Server mode:

<!-- State Server: out-of-process, shared across app pool recycles -->
<sessionState
    mode="StateServer"
    stateConnectionString="tcpip=127.0.0.1:42424"
    timeout="30" />

<!-- SQL Server: persistent, shared across multiple web servers -->
<sessionState
    mode="SQLServer"
    sqlConnectionString="data source=dbserver;
        Initial Catalog=ASPState;
        Integrated Security=True"
    timeout="30" />

All three modes work identically with the Pageless interception pattern. The SessionStateModule abstracts the storage backend — your code always reads and writes through HttpContext.Current.Session, regardless of where the data physically lives.

Part 3: Production Session Pattern — The AppSession Wrapper

In a production application, accessing HttpContext.Current.Session["key"] directly throughout your codebase creates two problems: stringly-typed keys are error-prone (a typo in "Usrname" silently returns null), and session logic (restoration, cleanup, validation) gets scattered across multiple files.

The solution is a static wrapper class that centralizes all session access behind strongly-typed properties and methods.

The AppSession Class

/// <summary>
/// Thin wrapper around HttpSessionState for the logged-in user.
/// All session access in the application goes through this class.
/// </summary>
public static class AppSession
{
    /// <summary>
    /// The currently logged-in user, stored in server session.
    /// Returns null if no user is logged in.
    /// </summary>
    public static obUser LoginUser
    {
        get
        {
            object o = HttpContext.Current?.Session?[AppSessionKeys.LoginUser];
            return o as obUser;
        }
        set
        {
            if (HttpContext.Current?.Session != null)
                HttpContext.Current.Session[AppSessionKeys.LoginUser] = value;
        }
    }

    /// <summary>
    /// Quick check for login status. Reads from session.
    /// </summary>
    public static bool IsLoggedIn => LoginUser != null;

    /// <summary>
    /// If no server session exists but the request carries a valid
    /// persistent login cookie, reload the user from the database
    /// and repopulate the session.
    ///
    /// Call once per request, early in the pipeline.
    /// </summary>
    public static void TryRestoreFromCookie()
    {
        // Already have a valid session — nothing to do
        if (IsLoggedIn) return;

        obUser user = UserSession.TryRestoreFromCookie();
        if (user != null)
            LoginUser = user;
    }

    /// <summary>
    /// Full logout: clears server session and deletes persistent cookie.
    /// </summary>
    public static void Logout()
    {
        UserLogout.Logout();
    }
}

/// <summary>Session key constants — prevents typos.</summary>
internal static class AppSessionKeys
{
    public const string LoginUser = "LoginUser";
}

The AppSession class stores the entire user object (obUser) in session rather than individual fields. This means a single session read gives you the user’s ID, username, display name, email, avatar URL, and any other user properties — no multiple lookups, no key synchronization.

The TryRestoreFromCookie() method bridges a critical gap: IIS InProc sessions are volatile. When the app pool recycles (which IIS does periodically by default), all sessions are lost. The user’s browser still has the ASP.NET_SessionId cookie, but the server-side data is gone. Without session restoration, every user is silently logged out on every app pool recycle. The cookie-based restore mechanism solves this transparently.

Hooking AppSession into the Pipeline

The TryRestoreFromCookie() method must run early in every request — after session is available, but before any page rendering checks IsLoggedIn. The PostAcquireRequestState event is exactly the right place:

// In Global.asax.cs:

protected void Application_PostAcquireRequestState(object sender, EventArgs e)
{
    // Session is available from this event onwards.
    // Silently restore the user from a "Remember Me" cookie if the
    // server session has expired but the cookie is still valid.
    if (HttpContext.Current?.Session != null)
        AppSession.TryRestoreFromCookie();
}

This runs on every request. The flow is:

  1. The SessionStateModule loads session data at AcquireRequestState (event 10)
  2. PostAcquireRequestState fires (event 11)
  3. TryRestoreFromCookie() checks if a user is already in session — if yes, returns immediately (fast path)
  4. If session is empty, it checks for a persistent login cookie
  5. If a valid cookie exists, it loads the user from the database and stores them in session
  6. All subsequent code in this request sees AppSession.IsLoggedIn == true

By the time any page rendering code executes — whether at PostAcquireRequestState itself or at a later pipeline event — the session is guaranteed to be in a consistent state.

Part 4: Persistent Login — The “Remember Me” Cookie System

The built-in ASP.NET_SessionId session has a fundamental limitation: it expires. The default timeout is 20 minutes of inactivity. InProc sessions are also lost when the application pool recycles. For a web application with user accounts, this means users are frequently logged out — which is unacceptable for most applications.

The standard solution is a persistent login cookie that outlives the server session. Here is a complete implementation.

How It Works

The persistent login system uses three components:

  1. A database table (login_sessions) that stores active login tokens
  2. A browser cookie (lsid) that carries the token between requests
  3. A restore method (TryRestoreFromCookie) that reconnects the two

The lifecycle:

Login with "Remember Me" checked:
    → Generate a cryptographically random 64-character token
    → Store the token in the login_sessions table (with user_id and expiry date)
    → Set a cookie named "lsid" with the token value (365-day expiry, HttpOnly, Secure)

Every subsequent request:
    → SessionStateModule loads session at AcquireRequestState
    → PostAcquireRequestState fires
    → AppSession.TryRestoreFromCookie() checks:
        → Is a user already in session? → Yes → return (fast path)
        → No → Is there an "lsid" cookie? → No → return (anonymous user)
        → Yes → Look up the token in login_sessions, JOIN with users table
        → Token valid and user active? → Store user in session → done
        → Token invalid/expired? → Delete the stale cookie → return

Logout:
    → Delete the token from login_sessions
    → Expire the "lsid" cookie
    → Clear the server session

The UserSession Class

/// <summary>
/// Persistent login session ("Remember Me").
///
/// Cookie: "lsid" (Login Session ID)
/// Expiry: 365 days
///
/// DB table: login_sessions
///   id, user_id, token (VARCHAR 64 UNIQUE), date_created, date_expiry
/// </summary>
public static class UserSession
{
    public  const string CookieName = "lsid";
    private const int    CookieDays = 365;
    private const int    TokenBytes = 32;   // produces 64-char hex string

    /// <summary>
    /// Create a persistent login token after successful authentication.
    /// Call this when the user logs in with "Remember Me" checked.
    /// </summary>
    public static void CreatePersistentSession(int userId)
    {
        string token     = GenerateToken();
        DateTime now     = DateTime.UtcNow;
        DateTime expires = now.AddDays(CookieDays);

        // Store token in database
        using (MySqlConnection conn = new MySqlConnection(config.ConnString))
        {
            conn.Open();
            using (MySqlCommand cmd = new MySqlCommand())
            {
                cmd.Connection = conn;
                MySqlExpress m = new MySqlExpress(cmd);

                var dic = new Dictionary<string, object>();
                dic["user_id"]      = userId;
                dic["token"]        = token;
                dic["date_created"] = now;
                dic["date_expiry"]  = expires;

                m.Insert("login_sessions", dic);
            }
        }

        // Set browser cookie
        SetCookie(token, expires);
    }

    /// <summary>
    /// Validate a persistent login cookie and return the user if valid.
    /// Returns null if no cookie, invalid token, or expired session.
    /// </summary>
    public static obUser TryRestoreFromCookie()
    {
        string token = GetCookieToken();
        if (string.IsNullOrEmpty(token))
            return null;

        using (MySqlConnection conn = new MySqlConnection(config.ConnString))
        {
            conn.Open();
            using (MySqlCommand cmd = new MySqlCommand())
            {
                cmd.Connection = conn;
                MySqlExpress m = new MySqlExpress(cmd);

                var p = new Dictionary<string, object>();
                p["@token"] = token;
                p["@now"]   = DateTime.UtcNow;

                // Single query: validate token AND load user data
                obUser user = m.GetObject<obUser>(
                    "SELECT u.* FROM login_sessions ls " +
                    "JOIN users u ON u.id = ls.user_id " +
                    "WHERE ls.token = @token " +
                    "AND ls.date_expiry > @now " +
                    "AND u.status = 1 " +
                    "LIMIT 1;", p);

                if (user == null || user.Id == 0)
                {
                    // Token invalid or expired — clear the stale cookie
                    DeleteCookie();
                    return null;
                }

                return user;
            }
        }
    }

    /// <summary>
    /// Delete the persistent session on logout.
    /// </summary>
    public static void DeletePersistentSession()
    {
        string token = GetCookieToken();
        DeleteCookie();

        if (string.IsNullOrEmpty(token))
            return;

        using (MySqlConnection conn = new MySqlConnection(config.ConnString))
        {
            conn.Open();
            using (MySqlCommand cmd = new MySqlCommand())
            {
                cmd.Connection = conn;
                MySqlExpress m = new MySqlExpress(cmd);
                var p = new Dictionary<string, object>();
                p["@token"] = token;
                m.Execute("DELETE FROM login_sessions WHERE token = @token;", p);
            }
        }
    }

    /// <summary>
    /// Delete ALL sessions for a user — use on password change or security reset.
    /// Forces re-authentication on all devices.
    /// </summary>
    public static void DeleteAllSessionsForUser(int userId)
    {
        DeleteCookie();

        using (MySqlConnection conn = new MySqlConnection(config.ConnString))
        {
            conn.Open();
            using (MySqlCommand cmd = new MySqlCommand())
            {
                cmd.Connection = conn;
                MySqlExpress m = new MySqlExpress(cmd);
                var p = new Dictionary<string, object>();
                p["@user_id"] = userId;
                m.Execute(
                    "DELETE FROM login_sessions WHERE user_id = @user_id;", p);
            }
        }
    }

    // ----- Cookie helpers -----

    static void SetCookie(string token, DateTime expires)
    {
        HttpCookie cookie = new HttpCookie(CookieName, token)
        {
            Expires  = expires,
            HttpOnly = true,   // Not accessible via JavaScript
            Secure   = HttpContext.Current.Request.IsSecureConnection,
            SameSite = SameSiteMode.Lax,
            Path     = "/"
        };
        HttpContext.Current.Response.Cookies.Set(cookie);
    }

    static string GetCookieToken()
    {
        HttpCookie cookie = HttpContext.Current?.Request.Cookies[CookieName];
        return (cookie?.Value + "").Trim();
    }

    static void DeleteCookie()
    {
        HttpContext ctx = HttpContext.Current;
        if (ctx == null) return;

        HttpCookie dead = new HttpCookie(CookieName, "")
        {
            Expires  = new DateTime(1970, 1, 1),
            HttpOnly = true,
            Secure   = ctx.Request.IsSecureConnection,
            Path     = "/"
        };
        ctx.Response.Cookies.Set(dead);
    }

    // ----- Token generation -----

    static string GenerateToken()
    {
        byte[] bytes = new byte[TokenBytes];
        using (var rng = new Security.Cryptography.RNGCryptoServiceProvider())
        {
            rng.GetBytes(bytes);
        }
        // 32 bytes → 64-character hex string
        return BitConverter.ToString(bytes).Replace("-", "").ToLower();
    }
}

Security Properties of This Design

Token strength: 32 bytes of cryptographic randomness (via RNGCryptoServiceProvider) produces a 64-character hex token. The probability of guessing a valid token is 1 in 2^256 — computationally infeasible.

HttpOnly cookie: The lsid cookie is marked HttpOnly, which means JavaScript cannot read it. This prevents cross-site scripting (XSS) attacks from stealing the persistent login token.

Secure flag: When the connection is HTTPS, the cookie is marked Secure, preventing it from being sent over unencrypted HTTP connections.

SameSite=Lax: Prevents the cookie from being sent on cross-site POST requests, mitigating cross-site request forgery (CSRF) attacks while still allowing normal navigation.

Server-side validation: The token is validated against the database on every restoration attempt. If a token is revoked (logout, password change, security reset), the next request with that token will fail validation and the cookie will be deleted.

Single-query validation: The TryRestoreFromCookie method uses a JOIN query that validates the token, checks expiry, and verifies the user is still active — all in a single database round-trip. This is important for performance because it runs on every request where the session is empty.

Force logout on all devices: DeleteAllSessionsForUser() removes every persistent session for a given user ID. Call this on password change or security breach to force re-authentication across all devices and browsers.

Part 5: The Two-Tier Interception Architecture

In a production Pageless application, requests are divided between two interception points based on whether they need session state:

Tier 1: Application_BeginRequest — Stateless

protected void Application_BeginRequest(object sender, EventArgs e)
{
    string path = Request.Path.ToLower().Trim().TrimEnd('/');

    // Block direct .aspx access
    if (path.EndsWith(".aspx"))
    {
        Response.StatusCode = 404;
        ApiHelper.EndResponse();
        return;
    }

    // Stateless API endpoints — no session needed
    switch (path)
    {
        case "/markdownapi":
            engine.MarkdownRequestHandler.HandleHttpPostRequest();
            break;

        case "/apichatroom":
            engine.HomePageChatRoom.HandleRequest();
            ApiHelper.EndResponse();
            break;

        case "/checkmessageengine":
            engine.HomePageChatRoom.CheckEngine();
            Response.Write("ok");
            ApiHelper.EndResponse();
            break;
    }
}

Endpoints handled here never touch HttpContext.Current.Session. They authenticate via other means (API tokens, request validation) or require no authentication at all. They execute before the SessionStateModule runs, which means zero session overhead — no session cookie lookup, no session store read, no session save on response.

Tier 2: Application_PostAcquireRequestState — Session-Aware

protected void Application_PostAcquireRequestState(object sender, EventArgs e)
{
    // Session is available from this event onwards
    if (HttpContext.Current?.Session != null)
        AppSession.TryRestoreFromCookie();

    string path = Request.Path.ToLower().Trim().TrimEnd('/');

    // Session-aware page rendering
    switch (path)
    {
        case "/":
        case "/home":
            PageRenderer.RenderHome();
            ApiHelper.EndResponse();
            return;

        case "/dashboard":
            PageRenderer.RenderDashboard();
            ApiHelper.EndResponse();
            return;

        case "/profile":
            PageRenderer.RenderProfile();
            ApiHelper.EndResponse();
            return;
    }

    // No match — fall through to ASP.NET
    // (static files or 404)
}

Every handler in Tier 2 can call AppSession.IsLoggedIn, read AppSession.LoginUser.Username, check permissions, and render personalized content — because the session was loaded by the module and restored from the cookie before any handler code runs.

Why Two Tiers?

Performance and clarity. Stateless API endpoints that handle high-frequency calls (markdown preview, chat room polling, configuration refresh) should not pay the cost of session state loading. By handling them at BeginRequest, the SessionStateModule never runs for those requests — no cookie parsing, no session store lookup, no session save.

Page rendering endpoints that need to know “who is this user?” must wait for session state. They run at PostAcquireRequestState, where the session is guaranteed to be available. The trade-off is a few milliseconds of additional pipeline processing — which is negligible compared to database queries and HTML rendering.

The two-tier model makes the dependency explicit: if an endpoint is in BeginRequest, it does not have session. If it is in PostAcquireRequestState, it does. There is no ambiguity. A developer reading the code knows immediately what resources are available in each handler.

Part 6: Session State — IIS Built-In vs Custom Implementation

There are two distinct approaches to session state in Pageless Web Forms:

IIS Built-In Session (This Article)

Uses the SessionStateModule that ships with ASP.NET. Configured in web.config. Session data is automatically loaded at AcquireRequestState and saved at ReleaseRequestState. Available via HttpContext.Current.Session.

Advantages: Zero implementation effort. Supports InProc, StateServer, and SQL Server backends with a single configuration change. Battle-tested across millions of deployments. Automatically handles session ID generation, cookie management, expiry, and concurrency locking.

Limitations: Not available at BeginRequest — requires waiting until event 11 in the pipeline. InProc sessions are lost on app pool recycle (mitigated by the persistent cookie system described above). Session locking in InProc mode serializes concurrent requests from the same user.

Custom Session Implementation

For applications that intercept at BeginRequest and need user identification, a custom session system can be built using encrypted cookies and database lookups — bypassing the SessionStateModule entirely. This approach is covered in a separate article.

Advantages: Available at BeginRequest — the absolute earliest point. No dependency on the SessionStateModule. Full control over storage, expiry, and serialization.

Limitations: You build everything yourself — session ID generation, cookie management, storage backend, concurrency handling, expiry cleanup. More code to write, test, and maintain.

Which to Choose?

For most web applications, the IIS built-in session with the PostAcquireRequestState interception point is sufficient and recommended. The SessionStateModule is proven infrastructure. The persistent cookie system handles the InProc volatility problem. The two-tier architecture keeps stateless endpoints fast.

Build a custom session only if you have a specific requirement that the built-in module cannot meet — such as needing session data at BeginRequest for every request, or needing a non-standard storage backend.

Summary

Session state access in Pageless Web Forms Architecture relies on the ASP.NET SessionStateModule, an IIS managed module that loads session data at the AcquireRequestState pipeline event (event 10 of 23). By intercepting requests at Application_PostAcquireRequestState (event 11) in Global.asax.cs, application code gets full read-write access to HttpContext.Current.Session without invoking any part of the Web Forms page lifecycle — no .aspx files, no System.Web.UI.Page instantiation, no control tree, no ViewState, no master page binding, no PreInit-through-Render event sequence.

The SessionStateModule operates independently of the page handler. It loads session data before the handler runs and saves it after the handler completes — even when the handler is not a page at all, but a custom method that writes directly to Response and calls CompleteRequest(). Session changes made at PostAcquireRequestState are persisted normally because ReleaseRequestState (event 15) still fires during the pipeline’s cleanup phase.

For production applications, session access is wrapped in a static AppSession class that provides strongly-typed properties (LoginUser, IsLoggedIn) and a TryRestoreFromCookie() method that bridges the gap between volatile InProc sessions and persistent login cookies. This method runs at PostAcquireRequestState on every request, transparently re-authenticating users whose server sessions have expired but whose browser cookies remain valid.

The complete architecture uses two interception tiers: Application_BeginRequest for stateless API endpoints that do not need session state, and Application_PostAcquireRequestState for session-aware page rendering. Both tiers bypass the Web Forms page lifecycle entirely. The only framework dependencies are the IIS HTTP request parser and the SessionStateModule — everything else is eliminated.

Companion Articles

aspnet-club.com | Github | Youtube | X.com | Facebook

© adriancs.com. All Rights Reserved.