Hello,

We are currently using OutSystems in production and have encountered a technical issue related to concurrent session (duplicate login) control. Given the urgency of this matter, we would greatly appreciate your prompt guidance.

Issue

Concurrent session control is not working as required. Our requirement is:

• Only one active session should be allowed per account.
• Example scenario: If Device A is already logged in and Device B attempts to log in with the same account, the user should receive an alert/confirmation message on the new device (Device B) indicating that another session is already active.
• Additionally, we need to define the expected behavior for which session should be retained (e.g., whether Device A's session is terminated, or the login on Device B is blocked until confirmed).

Environment

• OutSystems Version: 11.55.77
• Architecture: React-based web application, wrapped and deployed as a mobile app

What We Have Already Tried

• SingleUserSignIn (Forge component): We found this to be unusable, as it caused bugs when used across multiple modules.
• ConcurrentSessionControl (Forge component): This component forcibly terminates the existing session on Device A when a new login occurs on Device B, which does not match our intended behavior (we need a confirmation-based flow, not a forced termination).

Related Consideration – WebSocket

As part of our investigation into implementing real-time session notifications (e.g., alerting Device A when a new login attempt occurs on Device B), we also reviewed the previous guidance suggesting a WebSocket-based approach. Based on our technical review, it appears that OutSystems does not natively host a WebSocket server endpoint. Implementing WebSocket would require either:

1. Setting up a separate external WebSocket server, with OutSystems integrating via REST, or
2. Introducing an intermediate layer (e.g., a dedicated backend, proxy/gateway, or message broker) to handle WebSocket traffic.

Currently, we do not have the infrastructure in place to support a dedicated WebSocket server, and building one would introduce significant additional operational overhead (deployment, scaling, failover management, etc.), which is difficult for us to accommodate given our current resources.

Our Request

1. Is there a way to achieve the required concurrent session control (real-time notification and session confirmation) without setting up a separate WebSocket server — for example, using REST polling, Server-Sent Events (SSE), or another mechanism within the existing OutSystems architecture?
2. If WebSocket is genuinely required to meet this requirement, we would like to explore alternative approaches instead, given our infrastructure constraints.
3. We would also like your input on two potential approaches we are considering internally:
   • Rebuilding/customizing the SingleUserSignIn Forge component to resolve the multi-module bug issue, or
   • Separating the infrastructure environment while keeping a single OutSystems (Hanatour) domain/account, to see if this would resolve the conflict that caused the original SingleUserSignIn issue.

Urgency

This service is already deployed and actively used by field users in a production environment. Additionally, this requirement has been escalated internally by our Security team as a priority item that needs to be addressed as soon as possible. We understand this is a request specific to our internal circumstances, but we would sincerely appreciate your expedited review and guidance so we can move forward quickly.

Thank you very much for your support, and we look forward to your response at your earliest convenience.