Context

During development, an important nuance of MODX authentication became clear: after a user logs into the admin panel, their session state is added to the mgr context. If you then check authorization specifically in the web context, the user may be absent there.

At the same time, you cannot simply consider a user authorized based solely on the existence of a MODX session. Within the same physical PHP session, MODX allows different user identities for different contexts. That is, a single browser session can contain, for example, one user in mgr and another in web.

This is not a specific bug, but a consequence of the MODX architecture, where the authentication state is context-specific. For a detailed explanation, see the concept:

https://modx.club/concepts/modx-pays-for-rarely-used-complexity

Problem

The current authorization logic risks making one of two mistakes:

1. Checking only web and erroneously considering the user unauthorized, even though they are logged into the Manager (mgr).
2. Checking only for the presence of a shared MODX session and erroneously trusting it without understanding which specific user is authorized in the required context.

Both options are incorrect.

Goal

Make MODX authorization checks unambiguous and secure: explicitly account for the context, the actual contextToken, and the user identity, rather than inferring authorization state from indirect signs.

What to Study

• Exactly how MODX stores modx.user.contextTokens in the current version of the project.
• How mgr and web behave when different users log in sequentially within the same browser/PHP session.
• Which MODX APIs correctly return the user for a specific context.
• What happens upon logging out from just one context.
• How the session state behaves after updating permissions/cache and re-logging in.
• Whether the application specifically requires authorization in web, in mgr, or if an explicitly chosen trusted context is sufficient.

What to Do

• Remove logic that considers a user authorized solely based on the existence of a MODX session.
• Explicitly determine which context the check should run in for a specific scenario.
• Retrieve the user's identity/token specifically for the required context.
• If business logic allows authorization via the Manager, explicitly handle mgr as a separate valid identity source rather than trying to find the same user in web.
• Do not assume that the mgr user and web user in the same session are the same.
• If necessary, add a check to ensure user id/identity matches the expected scenario.
• Properly handle the absence of a token for the required context.
• Add diagnostic behavior for ambiguous states where different users are present in mgr and web.

Verification Scenarios

1. User is authorized only in mgr.
2. User is authorized only in web.
3. The same user is authorized in both mgr and web.
4. Different users are authorized in mgr and web within the same PHP session.
5. User logged out of web but remained in mgr.
6. User logged out of mgr but remained in web.
7. An outdated/invalid token exists in the session.
8. After resetting permissions/cache, the user state changes or requires re-login.

Result

Authorization is determined by the explicit state of the required MODX context and the specific user identity. The presence of a shared browser/PHP session is no longer treated as sufficient proof of authorization.

Definition of Done

• The check correctly distinguishes between mgr and web.
• Supports the scenario where a Manager user is authorized only in mgr.
• Different users in mgr and web are not mixed up.
• No trust in the session without checking the context-specific identity/token.
• All listed scenarios are covered by tests or reproducible checks.
• Behavior is documented so that the next developer does not treat the MODX session as a single global user state.

Architectural Reference

In MODX, a context is not just a set of settings, but also part of the security/authentication state. In a single physical session, modx.user.contextTokens can contain different user IDs for mgr and web. This is a fundamental feature of the platform, not a project-specific exception.

Source: https://modx.club/concepts/modx-pays-for-rarely-used-complexity