Session Lifecycle

Introduction

A Damsy ERP session begins when a user successfully authenticates and ends on logout, session timeout, or session abandonment. Throughout the session, ASP.NET stores company context, user identity, module flags, and integration settings server-side. Module navigation reuses the same session — no re-login per Area.

Purpose

This page provides an end-to-end lifecycle view connecting login, dashboard, module routing, in-module work, and termination — so you can reason about state persistence and security boundaries.

When to Use

Refer to this page when you:

• Design features that depend on session surviving across requests
• Debug unexpected logouts or missing session keys
• Plan session timeout messaging for users
• Document compliance or audit requirements for user sessions

How It Works

Full lifecycle diagram

Phase 1 — Anonymous

State	Session contents
First visit	Empty or ASP.NET session cookie only
Login GET	May set Version during software version check

No CompID → user sees login form.

Phase 2 — Authentication

Event	Session effect
POST login success	Session.Clear() then full key population
POST login failure	Session unchanged (failed attempt tracked separately)

Critical keys established: CompID, UserID, dtVerifyUser, SMTP, e-invoice URIs. See Session Management.

Phase 3 — Dashboard hub

Request	Behavior
/Dashboard/Index	Requires CompID; reads module flags from dtVerifyUser
Tile click	Same session; no new keys required

Phase 4 — Module navigation

Event	Session effect
ModuleManagement redirect	No session mutation — routing only
Area dashboard load	CompID gate; may set Module on shared screens
Admin sensitive action	May set Entryflag for re-auth

Session keys CompID, UserID, BranchCode, and integration keys are read repeatedly by DAL-bound controllers.

Phase 5 — Termination

Explicit logout (LoginController.LogOut):

1. FormsAuthentication.SignOut()
2. Session.Clear()
3. Session.Abandon()
4. Expire ASP.NET_SessionId cookie
5. Redirect to /Login/Index

Timeout / expiry:

• IIS/ASP.NET session timeout (configured in Web.config sessionState)
• Session_End in Global.asax.cs logs session ID and last known CompID
• Next request: Area gate finds empty CompID → redirect login

protected void Session_End(object sender, EventArgs e)
{
    string sessionId = Session?.SessionID ?? "UnknownSessionID";
    string userName = Session?["CompID"]?.ToString() ?? "Unknown";
    ErrorHandling.LogFileWrite(new Exception($"Session ended for user: {userName},id:{sessionId}"));
}

Session vs authentication cookie

Mechanism	Role
ASP.NET_SessionId cookie	Binds browser to server session state
Session keys	Primary authorization context for modules
FormsAuthentication	Sign-out on logout; not the main module gate

Developer Notes

• InProc session: Default ASP.NET session mode is typically InProc — web garden / multi-server farms require State Server or SQL session mode for sticky sessions.
• Session.Clear on login: Prevents privilege leakage between users on shared terminals.
• No sliding module token: Module access is not re-fetched on each request unless you add that logic — flags reflect login-time GetLoginUser result.
• AJAX after timeout: JSON endpoints may return errors; many views redirect to ManageError or login on HTTP 401-like behavior manually.

Refresh module flags

If admin changes user permissions in DB during an active session, user must log out and back in to refresh dtVerifyUser unless you add a refresh action.

Examples

Typical session duration workflow

09:00 Login → session created
09:05 Dashboard → Payroll module
12:30 Still active (sliding timeout extends session)
13:00 Idle beyond timeout
13:15 Click screen → redirect login CompID empty

Shared workstation pattern

User A LogOut → Session cleared cookie expired
User B Login → new Session.Clear + populate

Reading session in new Area action

public ActionResult Index()
{
    if (string.IsNullOrEmpty(Convert.ToString(Session["CompID"])))
        return RedirectToAction("UserLogin", "Login", new { Area = "" });

    ViewBag.CompName = Session["CompName"];
    return View();
}

Related Pages

• Login
• Dashboard
• Module Routing
• Session Management
• Authentication Flow
• Error Handling

Important Notes

Session is server memory

Large objects in session increase memory pressure. Keep dtVerifyUser lean — do not add attachments or report blobs to session.

CompID logged on Session_End

Log message uses CompID as user identifier — useful for correlating timeouts, not a display username.

Common Mistakes

Mistake	Consequence
Storing secrets client-side only	Server actions lack SMTP/IRN context
Never calling LogOut on shared PCs	Next user might inherit session if timeout not reached — mitigated by Clear on login
Expecting permission DB changes live	Stale module flags until re-login
Multiple browser tabs same session	Expected — session is shared across tabs
Abandon session without clearing cookie	LogOut handles both — do not skip cookie expiry

Next Steps

1. Review Error Handling for what users see when session expires mid-AJAX call.
2. Configure sessionState timeout in Web.config to match your organization's policy.