Using same app in two browser tabs. Safe?

I wonder if it is safe to use the same application in two different browser tabs.
For instance a form app to edit customer A and the same app to edit customer B, both open in two different browser tabs.
Is there a risk of session mismatch or overlapping ?
For sure any global variable will be overwritten

Why not?
What do you mean with is safe?
Both instances will be under the user session, previously authenticated, isnā€™t it?

I am not refering to any security risk.
I am more concerned about a risk of session overlapping and overwriting.
Suppose you have the same form opend twice in the same browser instance.
The two forms will share the same session.
Suppose now that in some event of the form, a global variable X is defined.
The user may work on form 1, changing the value of X, then move to form 2, work on it without realizing that the value of X has been ā€˜corrupted/changedā€™ while he was working of form 1.
If X is used to update the database the result can be catastrophic.

1 Like

Could be risky in terms of variables: if you declare a var when the app is loaded and then read its value when a buttons on the app is pressed you can have the following behavior:

  • app instance-1 is open and onLoad it sets [VarA] = ā€œYESā€
  • app instance-2 is open and onLoad it sets [VarA] = ā€œNOā€
  • on app instance-1 a button is pressed and it reads [VarA]: the value will be ā€œNOā€ (as set by instance-2 because it was open afterwards), when the expected correct value should be ā€œYESā€

Not 100% sure this will be the behavior with different browser tabs, but I know this happens when the same app is open in two menu tabs, so I suspect it will behave the same with different browser tabs

Basically if the same app is opened more than once in the browser, then global variables in the app must be used with extreme care because the working context of each single app can become mixed with the others.

I wish SC has a way to passing parameters from one app to the other without using global variable but using variable whose values stay local inside the app (what SC call Attribute, but as far as I know cannot be used for paramter passing)

1 Like

With forms app I use hidden virtual fields to store variables, if I know Iā€™ll open the same app in multiple tabs.
Reading the virtual field will return the correct per-instance value

2 Likes

You are right !!
I wish I had this discussion before.
In my projects I have overused global variable, where instead I should have used hidden fields as you suggested, and now I have a lot of session overlapping issues.

What about what SC call attributes ? Arenā€™t these a sort of hidden fields ?
Basically they have application scope , like fields.

Attributes

1 Like

I have no idea what Attributes are, Iā€™ve never used them.
Lately Iā€™m not working much in SC, so if you have time to test them, please let me know if they work as hidden fields in terms of storing per-instance variables :smiley:
Are those attributes available in both form and grid apps?
One issue with using virtual fields is that they are available in forms apps only.

Attributes are available in most of the apps, Form, Grid, Control, Blank, Report, Menu etc.
They behave like local variables with application scope, so their values is visible in all methods and events of the apps.
If we consider an App as a class in OOP terminology then attributes are like private data members.
They are NOT fields as they do not have any HTML visual appereance.

1 Like

WATCH OUT about SC attributes. They are NOT like private members in OOP.
They are shared between all instances of the same app.

1 Like

Just want to revive this conversation. Is there any definitive answer from SC devs or otherā€™s whoā€™ve experimented with this?
Iā€™m bumping up against being wary of using global vars for the reasons described above.
When @jefch mentioned the ā€œattributesā€ are shared by all instances, I assume that is within the same browser? can anyone else confirm this or not?
We have a need for multiple tab apps to be running different instances of the same app, each having different context as defined by their local variables. (especially considering the automatic session saving).
I really donā€™t want to have to clone an app for this purpose, and then have to maintain those two clones.
Has anyone worked with this type of setup successfully?
Thanks,

1 Like

I think itā€™s not a specific SC deficiency but itā€™s due to the way PHP sessions work.
Same URL , same browser, same cookie means same session ID.
If you have some data saved in session (a global variable, an attribute, etc) the same will be visible in all PHP apps (not necessarily SC apps) sharing the same URL and browser.
To avoid this problem the sessions must be kept separate.
One quick dirty solution is to use two browsers or the incognito session in Chrome but this is not something we can tell to our customers.
I have never tested the possibility to pass different session ID to each app and force each app to use its own session instead of the default session id saved in the cookie. This might be the solution notwithstanding the security risks involved

As this was a non-negotiable feature, I figured out something by myself.

  • When I open a tab (letā€™s say a client), I save their ID in a javascript variable (this variable is per instance compared to SC attributes)
  • at the same time I add a javascript listener like this ā€œwindow.addEventListener(ā€˜focusā€™, resetGlobalContactId);ā€
  • you can then open another tab with anotther client. When you come back to another client tab, the listener is called (here ā€œresetGlobalContactIdā€ . javascript function).
  • the ā€œresetGlobalContactIdā€ javascript function makes an ajax call to a separate PHP (and pass it the ID of the client). This PHP file takes care of resetting my session variables about the current client.

So far itā€™s working well, but I have come to this oly a few weeks ago and this has not yet been published in production. But Iā€™m pretty confident.

Any idea or remark about this ?

Letā€™s find the best way together.

  • everytime
2 Likes