I have a traditional and reactive Outsystems web application, both sharing the User data. I am allowing users to redirect between the traditional and reactive applications. Once a user redirects from Traditional to Reactive, and the same user does the same from a different laptop, then after sometime(less than 5 minutes), one of the user is getting session time out. This issue is not happening if both the users stay in the traditional application.
Appreciate your support.
Hello @Ummer Irshad Kandenkattil
When the same user opens an application in the browser (even before doing the login), he will start a session. If he does the same in another browser (in the same machine or in another one), he will start a different session. So, the behavior you are seeing should not be related to the fact it is doing it in two different computers, as the sessions are managed independently.
What I think is happening is the following.
From the documentation:
"To keep the session active, if you remain active in a reactive app, then the session for traditional web app is not extended. As a result, the traditional web app session expires, requiring you sign in again. For more information, see Troubleshoot SSO sessions for Traditional Web Apps. However, if you remain active in a traditional web app, the session is extended for all reactive apps."
When a user logs in in a Traditional Web App and than move to a Reactive App, the session in the Traditional app will not be maintained and will eventually expire, requiring you to sign in again.
There is a couple ways to mitigate this in this document.
Hope this helps.
Cheers.
The session is not expiring immediately (sometimes, not expiring until 5 minutes). I am sharing my service center configuration.
One thing I missed to mention is that, before redirecting from the traditional to reactive, I am creating a new user for the Reactive application. That means if the username in traditional, for instance, is 'william', then the logged in user in reactive would be 'william _reactive'. When the user returns back after the expiry, the Traditional user 'william' is still active and is displayed as logged in.
Hum... This is highly unusual...
You see, when the user OPENS the Reactive application from the Traditional app, because you have SSO, you are already logged in into the reactive application with the original user (from the Traditional app).
But it's not the SAME session.
If you log in with another user once you are in the Reactive (I am assuming you are doing this by code), I think the previous session will be ended. But I don't know what will be the effect on the Traditional app. I know the log in works, but I am not sure the log out works as well or in the same way.
By the documentation that I mentioned, the reactive app session does not keep the session of the traditional app. That's a fact.
Why are you doing this way, instead of just allowing the user to use the application with their own user, instead of logging in with a different user? If this is a necessity, may SSO between application types is not the way to go.
CheersEDIT:I am assuming the user_reactive already exists in the user entity...Do they have the right roles?How are you login in the new user?
If the issue only happens after redirecting back to the Reactive application, and not when the user stays in the Traditional application, then I would focus on the Reactive authentication/session configuration.
It may indicate that the Reactive session timeout is shorter, or that the Reactive application is not refreshing/validating the session as expected after the redirect.
Sharing the same User Provider/User Data does not necessarily mean both applications have the same runtime session behavior. Traditional and Reactive handle session/authentication differently.
I would suggest checking:
1. The session timeout settings in Service Center for both applications.
2. Whether SSO is enabled and configured consistently between Traditional and Reactive.
3. Whether the Reactive app performs an authenticated server call when the user lands there after the redirect.
4. Whether the first server call in Reactive is failing due to an expired session/token.
5. The Service Center logs at the exact time the timeout occurs.
A useful test would be to add a small server action in the Reactive screen OnInitialize/OnReady, for example a CheckSession action that calls GetUserId() and returns success/failure. This helps confirm whether the Reactive session is already invalid when the user lands on the page, or if it expires only after some idle time.
If the problem is confirmed to be the Reactive session timeout, the fix would be to align the timeout settings between the Traditional and Reactive applications and make sure the Reactive app revalidates the user when loaded after the redirect.
1. The session timeout settings in Service Center for both applications:
Both are having same settings.
2. Whether SSO is enabled and configured consistently between Traditional and Reactive: Yes, enable for both
3. Whether the Reactive app performs an authenticated server call when the user lands there after the redirect:
No, the Reactive application is sometimes able to do some actions and the session is expiring after a while (but not while inactive)
The service center log says that the role check failed.
You are right, if it happens in less than 5 minutes, then the "Cache Time In Minutes = 5" is probably not the direct cause of the issue.
However, the most important clue seems to be the Service Center log: "role check failed".
Also, the fact that you are using different users is very relevant. If the Traditional application authenticates the user as "william" and the Reactive application authenticates/creates another user such as "william_reactive", those are two different OutSystems users, with different UserIds, different roles and different authentication/session context.
SSO between app types is intended to share authentication between Traditional, Reactive and Mobile apps using the same User Provider/user. It is not meant to safely switch from one OutSystems user to another during the redirect.
I would first check which user is actually logged in in the Reactive application when the issue happens.
Could you log the value of GetUserId() in the Reactive application when the timeout/role check error happens?
Depending on the result:
If GetUserId() returns the UserId of "william_reactive", then the Reactive user is still logged in, but probably does not have the required role for the screen/action being accessed.
If GetUserId() returns NullIdentifier() or an anonymous user, then the Reactive session/authentication is being lost.
If GetUserId() returns the UserId of "william", then the redirect/login to "william_reactive" is not actually happening as expected, and the Reactive app is still running under the Traditional user context.
So, in my opinion, this does not look like a simple session timeout anymore. It looks more like an identity/role mismatch caused by using "william" in Traditional and "william_reactive" in Reactive.Also check which exact role failed in Service Center, because that will probably point directly to the screen/action causing the issue.