Session Management

PHP Session Modes

How your users' sessions are stored has a direct impact on what your hosting can look like. A single web server can keep session files on its own disk and never think about it; the moment you put two web servers behind a load balancer, those file-based sessions stop working unless you switch to a shared store. ActiveManage supports four session modes and the right one for you depends entirely on your deployment shape.

The setting that drives this is PHP Session Mode under Site Settings → Session. You'll typically pick a mode once at install time and never touch it again, but if your infrastructure changes — for example you migrate from a single Apache box to an AWS Beanstalk auto-scaling group — you'll come back to revisit it.

files

The standard PHP session mode and the platform's default. Session data is written to files in a temporary folder on the web server itself (typically /tmp or the directory set in session.save_path). It needs zero additional infrastructure, runs everywhere PHP runs, and is the simplest mode to debug because you can literally cat a session file.

The downside is that sessions are pinned to one web server. If your hosting later puts a load balancer in front of multiple servers, a user who logs in on server A and is then routed to server B will look unauthenticated, because server B can't see server A's session files. Some load balancers can be configured for sticky sessions to work around this, but it's a fragile arrangement.

Use files mode when: you're running a single web server, you're in development, or you're confident you'll never need to scale out horizontally.

redis

Sessions are stored in a Redis database — an in-memory key-value store known for very low-latency reads and writes. Redis is the de-facto choice for load-balanced PHP deployments because every web server reads sessions from the same Redis instance, so requests can be served by any server and find the right session.

You'll need a Redis server reachable from each web server. Common patterns: a dedicated EC2 instance running Redis, an AWS ElastiCache for Redis cluster, or a managed Redis service like Redis Cloud or Upstash. Configure the hostname and port via the Session Server Hostname and Session Server Port Site Settings.

Use Redis mode when: you're running multiple web servers behind a load balancer, you want fast session reads, and you have (or can spin up) a Redis instance.

memcached

Sessions are stored in a Memcached system. Functionally similar to Redis — multi-server-friendly, fast — but with a simpler feature set (no native persistence, simpler data types). The choice between Redis and Memcached usually comes down to whatever's already running in your infrastructure rather than any meaningful capability difference for session storage specifically.

Like Redis, you'll point ActiveManage at a Memcached host via the same Session Server Hostname and Session Server Port settings. AWS ElastiCache supports both, so on AWS the decision often comes down to whether you also need Redis's broader feature set for other parts of your stack.

dynamodb

Sessions are stored in an AWS DynamoDB table. This is the right pick for serverless or auto-scaling deployments — DynamoDB is fully managed, scales automatically, and doesn't require you to size and maintain a Redis or Memcached instance.

Configure the endpoint via $AM_awsDDBendpoint and the table name via $AM_awsDDBsessionTBL in your config. The AWS credentials configured for S3 and SNS are reused. DynamoDB read/write costs are typically negligible for session traffic — each request is a single small read and (occasionally) a small write.

Use DynamoDB mode when: you're deploying to AWS and want zero session-server management, or you're running in a serverless environment where keeping a long-running Redis/Memcached process around is awkward.

Choosing the right mode for your deployment

To summarise the typical decision matrix:

• Single server, internal tools, dev/staging: files.
• Load-balanced production on your own infrastructure: Redis (or Memcached if it's already there).
• AWS production with autoscaling: DynamoDB, or Redis via ElastiCache.
• Serverless (Lambda-based deployments): DynamoDB.

Note: Changing modes mid-flight will log out every currently-authenticated user because their existing session data lives in the old store. Plan a maintenance window for any mode change in production.

Always Check Session

By default, ActiveManage trusts the session cookie that arrives with each request. If the cookie matches a known session ID and the session hasn't expired, the user is treated as authenticated. That's fast — there's no extra database lookup per request — but it has a downside: if you revoke a session in the admin panel (say, because you suspect a hijack), the user with the stolen cookie can keep using it until the session naturally expires.

The Always Check Session setting changes that. When on, every request hits the session store (Redis, Memcached, DynamoDB, or the session-files directory) and verifies the session is still considered valid. Revocations take effect immediately. The trade-off is one extra round-trip per request — usually a millisecond or two against Redis on the same network, more against DynamoDB or files.

What "checking" actually does

With Always Check Session enabled, every page load (and every AJAX request) the platform serves runs three additional pieces of logic before the user is considered authenticated:

1. Look up the session by ID in the configured session store.
2. Confirm the session hasn't been marked as revoked, expired, or invalidated by an admin action.
3. If two related settings are also on (covered in their own articles), verify the IP address and User Agent haven't changed since login.

If any of those steps fail, the user is silently logged out and redirected to the login page. Their previous request isn't fulfilled — they have to log back in to continue.

When to enable

There are three concrete situations where the cost of the extra lookup is worth paying. The first is any environment with strict regulatory requirements — healthcare, banking, payments — where stale sessions are unacceptable. The second is when you've built a "log out everywhere" feature in your application; without Always Check Session, that feature can't actually log users out until their sessions naturally expire. The third is when session hijacking is a concrete concern, typically because your app handles particularly sensitive data and you want every layer of defence available.

When to leave it off

For high-throughput consumer apps where session theft isn't a primary threat and the marginal latency matters, leave it off. The default "trust the cookie" model is what most PHP applications use and it's been good enough for the vast majority of the web for two decades. A B2C content site, a marketing portal, or a low-stakes self-service tool doesn't need the extra cost.

Performance budget

To put numbers on it: against a same-region Redis or Memcached, the extra lookup is around 0.5–2ms per request. Against DynamoDB it's typically 5–15ms. Against files-on-disk (rare for large deployments) it's whatever the disk I/O latency is, which can range from sub-millisecond on SSDs to many milliseconds on overloaded shared hosting.

Tip: If you enable Always Check Session, you'll typically also want to think about Maximum Session Idle Time (separate setting). Together they give you: "any revocation takes effect immediately" and "sessions auto-expire after N minutes of inactivity".

Verifying IP and User Agent

If an attacker manages to steal a user's session cookie — by intercepting traffic, exploiting an XSS bug, or pinching it off an unattended device — they can typically use it from anywhere, on any browser. ActiveManage offers two additional checks that make stolen-cookie attacks much harder, at the cost of some inconvenience for legitimate users whose connection or browser legitimately changes mid-session.

Both settings sit under Site Settings → Session and both only take effect when Always Check Session is also on — without that, the platform doesn't look up the session per request and so can't run the comparison.

Verify User's IP Address

When this is on, the platform stamps the user's IP into their session at login. Every subsequent request compares the incoming IP to the stamped one. If they don't match — typically because the user moved between networks — the session is invalidated and the user is forced to log back in.

For desktop users sitting at a single workstation all day, this is invisible. For mobile users it's a constant nuisance: walking from the office Wi-Fi to the lift's 4G connection counts as an IP change, as does the morning commute moving between cell towers. Most modern apps avoid IP-pinning for this reason.

There's a third group it's actively wrong for: users behind carrier-grade NATs (often the case in mobile networks) where the apparent IP can rotate every few minutes without the user moving at all. In those environments, IP-pinning effectively logs the user out constantly.

The platform's own documentation captures the right summary: this option isn't recommended for mobile users that switch between mobile and Wi-Fi connections. Enable it for hardened admin-only environments; leave it off for anything customer-facing.

Verify User's Browser User Agent

This compares the visitor's browser User-Agent header against the User-Agent stamped at login time. A mismatch — almost always because the browser auto-updated mid-session — logs the user out.

It's less intrusive than IP-pinning because most browsers' User-Agent strings stay stable for hours or days at a time. It catches the easiest form of cookie theft, where an attacker grabs the cookie and pastes it into a different browser entirely.

The catch: anti-tracking browsers like Brave and Safari sometimes randomise User-Agent components for privacy. And every Chrome auto-update flips the version number, which counts as a change. Test in your user population before turning it on.

Combined effect

With both on, an attacker who steals a session cookie would need to spoof both the original IP and the original User-Agent to use it. That's hard. The legitimate-user cost is real though — IP changes from network roaming, plus User-Agent changes from browser updates, mean users see unexpected re-login prompts every few days.

Recommended configurations

Three sensible profiles, depending on your threat model:

• Maximum security (internal admin tools): Always Check Session + Verify IP + Verify User Agent + short Idle Time (15 min). Locks down hard at the cost of UX.
• Balanced (typical business apps): Always Check Session + Verify User Agent only. Catches obvious cookie theft without disrupting mobile users.
• Convenience-first (consumer apps, marketing portals): Always Check Session off; rely on session expiry and HTTPS for cookie protection.

Warning: If you're considering enabling IP verification for an app with any mobile usage, run it past your support team first. They'll be the ones answering "why did I get logged out again?" tickets.

Setting Maximum Session Idle Time

Every session has an idle timer that resets on activity. When the user goes idle for longer than the configured maximum, their session is invalidated and they're forced to log back in. That's the primary defence against unattended-device risk — someone walking away from their desk, closing the lid of their laptop without locking it, leaving a session live in a browser tab forever.

The setting lives at Site Settings → Session → Maximum Session Idle Time, and it's expressed in seconds. The default in the shipped configuration is 1,209,600 seconds — exactly two weeks. That's deliberately generous: it's a value that suits consumer apps where convenience trumps strict security. For business apps, you'll typically want to bring it down significantly.

What counts as activity

Any HTTP request that includes the session cookie resets the idle timer. That includes:

• A page navigation (clicking a link, submitting a form).
• Any AJAX call the page makes — saving a row, loading a dropdown, fetching a notification count.
• A polling request from the platform's real-time poller (if Polling is enabled).
• Any browser background tab that's open and periodically pinging the server.

That last point is important: a user with the platform open in any background tab will not appear idle even if they're nowhere near the screen. Apps that include client-side polling effectively never auto-log-out their users while the tab is open. If you need stricter behaviour, combine the idle time with a separate "hard timeout" via custom JS that logs the user out after N minutes of no mouse/keyboard activity.

Picking a value for your app

Three concrete recommendations based on different app types:

• Banking, healthcare, payment processing — 900 seconds (15 minutes). Conventional in regulated industries. Some standards (PCI-DSS in particular) mandate timeouts in this range.
• Internal business apps — 14,400 seconds (4 hours). Long enough that a typical working session doesn't get interrupted, short enough that a desk left for a long meeting will require re-authentication.
• Consumer apps — 1,209,600 seconds (2 weeks). Conventional for B2C — users get frustrated if they have to log in again every visit.

You can also segment by surface. If your platform has both an admin panel and a customer portal, consider a tighter idle time for admin sessions and a looser one for portal sessions. That's typically configured via custom code (the underlying setting is global) but it's worth implementing for any app where admins handle sensitive data.

Coordinating with Always Check Session

The idle timeout is enforced regardless of Always Check Session. When that setting is off, the timeout is checked at request time using the session cookie's age; when it's on, the timeout is checked against the session's last-activity timestamp in the configured store. The effective behaviour is the same — only the implementation differs.

What the user sees when they time out

Their next request after the timeout returns to the login page rather than completing. If they were in the middle of filling in a long form, they'll typically lose their unsaved input. To avoid that frustration for users with high-value forms (UIVs, complex Custom Forms), consider implementing client-side draft-save logic that persists in-progress form data to localStorage on every change.

Tip: Test your chosen idle time with a real user workflow before going live. A 15-minute timeout that interrupts the typical user's day every few hours quickly becomes a major source of support tickets and lost work.

Note: Both Always Check Session and IP/User-Agent verification operate independently of the idle time. You can have a long idle time but short revocation latency, or a short idle time but no per-request session lookups — they're orthogonal levers.

The shipped default is fourteen days

Maximum Session Idle Time ships at 1,209,600 seconds — fourteen days. That suits a personal device used by one person, and it does not suit a shared workstation, a hot desk, a ward or a laptop that might be lost: a browser left open stays signed in for a fortnight.

Shorten it to match the worst case you can reasonably expect rather than the typical one — 15 to 30 minutes for shared or public machines, a few hours for ordinary office use. Enable the timeout warning whenever you shorten it, because a short timeout without notice means people lose half-completed work and the organisation lengthens it again.

Session Timeout Warning

The session timeout warning shows a countdown shortly before an idle session ends, so people can choose to stay signed in instead of losing what they were doing. It makes a short idle timeout practical: switch it on whenever you shorten Maximum Session Idle Time.

Where to find it

Architect Panel → Configuration:

• Site Settings — Warn Before Session Timeout, Warn This Many Seconds Before Timeout and When the Countdown Reaches Zero, beside Maximum Session Idle Time

Architect Panel → Security:

• Security Check-up — the Idle timeout and Warn before an idle session ends rows, in the Sessions section

The settings

• Warn Before Session Timeout: switches the warning on. Ships off; while it is off, nothing is added to pages and nothing runs.
• Warn This Many Seconds Before Timeout: how long before the session ends the countdown appears. Ships at 120 seconds. If you set it as long as the idle timeout or longer, the platform uses half the idle timeout instead, so the warning is never on screen from the moment a page loads.
• When the Countdown Reaches Zero: Keep the page open (the default) or Return to the sign-in page.

The countdown itself is driven by Maximum Session Idle Time in the same group. See Setting Maximum Session Idle Time.

What people see

When the time comes, a dialog titled Are you still there? says "You've been inactive for a while, so we're about to sign you out to keep your account secure." under a minutes-and-seconds countdown, with two buttons:

• Stay signed in: tells the server the person is still there and restarts the idle period.
• Log out now: signs out straight away, which is the right choice on a shared computer.

If the countdown reaches zero untouched, Keep the page open leaves the page as it is and shows a sign-in dialog over it, so anything half-typed is still there after signing back in. Return to the sign-in page signs the person out and leaves the page, so unsaved work is lost; it suits kiosks and shared machines.

The countdown follows the server

The time left comes from the server, not a guess in the browser. Every response the page receives updates it, and before the dialog appears the page checks with the server without extending the session. So somebody working in another tab is not interrupted by a warning in a tab they left open, and a laptop that has been asleep does not show a countdown for a session that has already ended. The sign-in page never shows the warning.

Switching it on

1. Open Site Settings and find Maximum Session Idle Time. Decide the idle timeout first; the warning is only useful when it is reasonably short.
2. Switch on Warn Before Session Timeout.
3. Set Warn This Many Seconds Before Timeout. Two minutes suits most people; give longer if your users fill in long forms.
4. Choose When the Countdown Reaches Zero: keep the page open for offices, return to the sign-in page for shared or public machines.
5. Click Save Settings for the group.
6. Test it: temporarily set a short idle timeout on a test installation, sign in, leave the page, and check the dialog and both buttons.

What goes wrong

• No warning ever appears. Check the setting is saved, that the person is signed in on an ordinary page, and that the idle timeout is long enough for the warning to fall within it.
• The warning appears almost immediately. The warning time is close to the idle timeout. Shorten the warning or lengthen the timeout.
• People lose work when the countdown ends. When the Countdown Reaches Zero is set to Return to the sign-in page. Switch to Keep the page open unless the machines are shared.
• Somebody is never signed out. The warning does not change when a session ends; only the idle timeout does. A page that keeps making requests in the background keeps its session alive.

Worked example

A clinic shortens its idle timeout from fourteen days to fifteen minutes after a Security Check-up. It switches on the warning at 120 seconds and chooses Keep the page open, because clinicians type long notes. A week later reception asks for stricter behaviour on the front-desk PCs. As the setting is installation-wide, the clinic keeps Keep the page open and trains reception staff to use Log out now when they step away.

Recommendations

• Switch the warning on whenever you shorten the idle timeout.
• Keep the page open unless your users share machines.
• Allow longer warnings where people fill in long forms.
• Remember the warning is a convenience, not a control; the idle timeout is the control.