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:
- Look up the session by ID in the configured session store.
- Confirm the session hasn't been marked as revoked, expired, or invalidated by an admin action.
- 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".