REACT - Replacing Session Variable with sensitive data by what?

Ok guys,

we are starting to replace our WEB applications with REACT.

I understand that while we are in a transition, we need to have 2 logins (second in the background). One will occur in the Login page already in REACT, and the other will occur in the background for the WEB part, with a bunch of workarounds already provided by support, which by the way, already have in their roadmap an implementation of transparent login between react and web for the same user provider.

Now, we are in other step, which is, we need to start replacing Session Variables. Some of them will be quite easy to change, they can be client variables. And if some "smart guyinspects and change its data, won't hurt anyone, because this is just some constants depending on the user in session. 

But we do have a few, or at least one Session Variable with sensitive data, and so, we cannot have it visible to our "smart" users. But we need to have it always available as it depends on the session, and varies depending on the userid in session. We use it to query almost all our aggregates and advance queries.

Do you guys have any suggestion of what should we use to replace this session variable? We have thought about:

  • Creating a secure Token
  • Save it in the database and have a cached action/query to get that data.
  • Unfortunately this is all we got so far

Any more suggestions??

Thanks in advance!!


Hello Nelson

I think the way you're thinking is right. 

A session variable is stored as string in the Session database, associated with the Session. Every request makes the platform automatically deserialize them and create them in memory and at the end of the request, update them in the database. It is recommended, even, that if you have too many session variables, you create your own session variable management system, to avid the serialization/deserialization and fetch of everything from the database every request.

So, I would say that in React, on the absence of a "session" (but I think there is a token created as the login session also times out), you have to implement your own "session management" using the database.

At least for now, there is no other easy way, I think...


We are gearing up to launch a client facing website project with Reactive web as the chosen path, what is this you're talking about secondary log ins and insecure variables? I thought the platform catered for these. 

Can you provide more information before we run into this invisible wall?

Hi Mariano,

we have hundreds of screens in WEB, and we want to convert them to REACT. Obviously we don't want to release all of them at once, so we need to have a transition, that is, every 2 weeks or so, release 3 or 4 screens (increasing exponentially). OutSystems does not have the WEB session and REACT session connected (yet), So, imagine the following scenario:

  • You have this link:
    and this link
  • Both modules uses the same user provider, example User
  • You Have the Login page in ModuleInReact
  • Both screens Employee and Opportunity are not anonymous
  • You log in in ModuleInReact, go to Employee page, click on a link to go to the Opportunity.aspx?Employee=1111
  • You will get a "SecurityException" because you are not logged in

This is because you are logged in REACT but not in WEB, as Outsystems didn't connect both sessions yet. According to the support case that I've created, it's on Outsystems roadmap, just don't know when will it be out.

So, in the meantime we need to get a workaround to whenever you log in REACT, you need to re-login in WEB (in the background without the user to notice it), and Vice-Versa, in order to navigate smoothly between REACT and WEB.

But, if both modules are in REACT, then there is no problem. This is only for who is in transition, which I believe it will be a lot of customers in a short term.

Regarding my question, I'm inclined to go to a secure and httponly cookie instead of using the database, to remove some weight from the database, as we have half million active users, and we always had aspdatabase session issues. If any of you knows something that should prevent me to go to this solution, let me know, I'm all ears (or eyes :) )


Hi Mariano,

Secondary logins it's because there is still no SSO (single sign-on) between reactive and traditional web apps. This only applies to customers who have both and there is already a forge component for this, but we intend to provide a better solution soon.

As for insecure variables, client variables and client actions are done in JavaScript so we recommend all sensitive data and security validations to be done on the server side (i.e. storing sensitive data only in the database and putting authentication logic on server actions).

Tiago Simões

Hi Tiago,

based on what you said, I've changed my mind, and created an entity "Session" which contains the UserId (PK and FK) and the attribute that used to be a session variable.

Then, I have a Server Function with a cached aggregate that basically do "SELECT FROM Session where Session.UserId = GetUserid()"

Hopefully this doesn't mess around to much with the database. Will have hundreds of simultaneous selects, but only writes once at the first login for each user.

The Cookie approach although its called in the server side, I agree it writes in the browser, so its kind of a client thing, even with the "secure" and "httponly" options active.

Thank you again,