ThoughtSpot For Developers•2y ago

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:

We are embedding ThoughtSpot liveaboard into our Virsec app
as part of Virsec customer onboarding we are creating
1. new org
2. new user with read privileges
using the new user to login into TS from Virsec app

issue we are noticing is:

admin logs in virsec.thoughtspot.cloud
opens virsec app in another tab
we notice that now admin user is logged in as embedded user in virsec app rather than newly created user.

Aditya•7/31/24, 12:45 PM

Hi @Murali Krishna What is the authentication method that you are using?

Vikaschandra•7/31/24, 2:54 PM

@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.

Myles Loffler•7/31/24, 3:48 PM

Hey there, I'm not Murali, but my team has a similar use case and experiences the same behavior.

We use 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 and a
```
clientId
```
```
clientId
```
cookie if logged in at *.thoughtspot.cloud and only
```
clientId
```
```
clientId
```
if not logged in.
In both cases, the parameters sent with the reques tinclude:

Myles Loffler•7/31/24, 3:57 PM

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 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 . If I'm logged out, the application authorization is used as expected and they are not available.e

Myles Loffler•7/31/24, 4:08 PM

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 cookie in either case.

Inspecting browser storage, Firefox seems to be isolating the cookie differently. It is not visible in the cookies from my application URL in Firefox, but it is listed in Chrome.

ashish•7/31/24, 5:20 PM

@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.

Myles Loffler•7/31/24, 8:31 PM

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.

Myles Loffler•7/31/24, 8:33 PM

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.

ashish•7/31/24, 10:11 PM

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.

Sandeep Yadav•8/1/24, 4:56 AM

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?

Screenshot_2024-08-01_at_10.24.15_AM.png

Sandeep Yadav•8/1/24, 4:59 AM

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

Screenshot_2024-08-01_at_10.29.29_AM.png

Myles Loffler•8/1/24, 2:50 PM

Thanks for digging into that for us, @Sandeep. I will do that.

VVikaschandra @Murali Krishna Have you tried TrustedAuthTokenCookieless ? It's quite easy to e...

Murali KrishnaOP•8/2/24, 4:18 PM

yes @Vikaschandra we are using trusted auth

Sandeep Yadav•8/5/24, 6:08 AM

Hello @Myles Loffler : Could you please confirm if the issue is resolved after the flag is updated.

Hello @Murali Krishna : As mentioned here: Hello team, This is Murali from Virsec., Could you please raise a support ticket to get the flag updated and confirm if this resolves the problem

Murali KrishnaOP•8/5/24, 7:38 AM

@Sandeep we have raised support ticket. Will let you know if its fixed

Myles Loffler•8/6/24, 6:57 PM

@Sandeep, we have an update scheduled. I will follow up when we know the results.

Myles Loffler•8/7/24, 5:47 PM

@Sandeep, our update was applied last night and seems to have resolved the issue for us. Thanks!

Sandeep Yadav•8/8/24, 5:06 AM

Thanks for confirming @Myles Loffler .

Murali KrishnaOP•8/8/24, 12:14 PM

its fixed now @Sandeep Thank you