Hello team, This is Murali from Virsec.
Hello team, This is Murali from Virsec. I was wondering if you can help me with an issue I have noticed.
current setup:
1. We are embedding ThoughtSpot liveaboard into our Virsec app
2. as part of Virsec customer onboarding we are creating
1. new org
2. new user with read privileges
3. using the new user to login into TS from Virsec app
issue we are noticing is:
1. admin logs in virsec.thoughtspot.cloud
2. opens virsec app in another tab
3. we notice that now admin user is logged in as embedded user in virsec app rather than newly created user.
16 Replies
Hi @Murali Krishna What is the authentication method that you are using?
@Murali Krishna Have you tried TrustedAuthTokenCookieless ? It's quite easy to embed using it, you'll just need the token of the logged-in user.
👋 Hey there, I'm not Murali, but my team has a similar use case and experiences the same behavior.
We use
AuthType.TrustedAuthTokenCookieless and if we're signed in to our *.thoughtspot.cloud domain when accessing our app (which creates users for itself), that user is preferred to the cookie auth.
We've worked around this so far by logging out, using a private window, or another browser, but that's a stopgap and prone to confusion. I've been meaning to ask this same question.
For a little more context:
- The SDK is requesting tokens
- The document request for the embedding includes a JSESSIONID and a clientId cookie if logged in at *.thoughtspot.cloud and only clientId if not logged in.
- In both cases, the parameters sent with the reques tinclude: authType: AuthServerCookieless
I do see a good number of requests being made with the token in either case, but interactions within the embedded application are not associated with the user associated with the token if there is a session with *.thoughtspot.cloud available.
For example, we have a SearchEmbed and the effect can clearly be seen in the available data points. My admin user has more access and can see data points the app user cannot.
If I'm logged in, I see those datapoints in the SearchEmbed. If I'm logged out, the application authorization is used as expected and they are not available.e
One last thing I just noticed: this might be dependent on the browser in use.
I typically use Chrome (currently 126.0.6478.127). I DO NOT seem to be experiencing the same behavior with Firefox (currenty 128.0) and it IS NOT sending the JSESSIONID cookie in either case.
Inspecting browser storage, Firefox seems to be isolating the JSESSIONID cookie differently. It is not visible in the cookies from my application URL in Firefox, but it is listed in Chrome.@Myles Loffler so cookie is taking precedence in some cases for you ?
Fwiw, We are introducing partitioned cookies soon for chrome, that should take care of the behavior you are seeing.
That's correct, if a session cookie exists from *.thoughtspot.cloud it is being used for actions within embedded components, but only in Chrome. I also later noticed warnings related to cross-site context in the Chrome console.
Within Chrome, the cookie that is causing the trouble is also marked with ⚠️ (presumably because of the upcoming changes). In Firefox, as noted, it seems that it's simply not part of the context and that resolves the issue.
I expect your right about partitioned cookies resolving the behavior.
Roughly when could we expect those changes? If there's nothing you can share, I undertand. Anything you do share I'm not going to take as a commitment, just hoping to be able to share something with my team.
So Firefox partitions the cookies by default. So thats why you do not see the behavior there. The token should be taking the precedence otherwise, and we might need to have a call to repro with you on that one.
Partitioned cookies it around 3 months out approximately.
Hello @Myles Loffler
I checked the Vellum cluster configuration and found that the jSessionIdPrecedenceOverToken flag needs to be toggled to false to ensure token precedence. Currently, it’s set to true.
Could you please raise a support case to update this setting?
Hello @Murali Krishna : Seems like for Virsec as well the above configuration needs to be updated to correct the behaviour of honoring the token instead of session when both are present in the request header
Thanks for digging into that for us, @Sandeep. I will do that.
yes @Vikaschandra we are using trusted auth
Hello @Myles Loffler : Could you please confirm if the issue is resolved after the flag is updated.
Hello @Murali Krishna : As mentioned here: https://discord.com/channels/1143209406037758065/1268157840925655123/1268432939176427540, Could you please raise a support ticket to get the flag updated and confirm if this resolves the problem
@Sandeep we have raised support ticket. Will let you know if its fixed
@Sandeep, we have an update scheduled. I will follow up when we know the results.
@Sandeep, our update was applied last night and seems to have resolved the issue for us. Thanks!
Thanks for confirming @Myles Loffler .
its fixed now @Sandeep Thank you