Hi team! I am using Thoughtspot Embed
Hi team! I am using Thoughtspot Embed SDK to embed a liveboard into an application and we are currently trying to use Token auth with Cookies. We want to make sure that when a user logs out of our application that their TS session gets invalidated, requiring them to retrieve a new token. Within the application, I tried calling the
logout() SDK method when a user logs out, however this doesn't always work:
- If the user is in another part of the app (a different SPA that is part of the same application), then logout doesn't actually invalidate the session.
- In addition, if we try to logout the user before they initialize the Thoughtspot embed, it also won't work.
In the cases above, the user will still be able to log in to Thoughtspot without needing to request a new token.
We were thinking maybe we'll have to manually call the REST API to logout the user, do you know how we would go about doing this? Or if there is an easier way? Thanks!36 Replies
You can call the REST API to log out the user when the user logs out of your application (It may throw an error if the user has not initialized Thoughtspot embed, but you may try to repress the error). I will try to ask the team internally if we have a better way to do that..
@yuichirio_ha
Hey there! So that makes sense to call the logout endpoint, but that requires a bearer token which the user may not have without requesting a new token (which wouldn't be great to do every time the user logs out unfortunately). I'd think there should be some way to clear out some local data that determines your login status without having to call the endpoint, although I wasn't able to easily find any data locally. I was thinking though we might have to call the
force-logout endpoint from the back end that directly determines by user id which users to log out but that also requires a bearer token (which the back end may not have).You can check if the back end has bearer token and then take the relevant action? Won't that work?
Hi there @shikharTS ! We tried this without any luck. Seems like after logging the user out of their session, they are still able to access that session without a token.
After logging out is your code calling the TS init call again? @jbc can you help understand how the session might be still valid after session has been logged out?
Hey @shikharTS ! Thanks for the response. Yeah we call the standard
init() method in our code, which should usually call the getToken method if there isn't a session. However, even after calling the logout endpoint, it doesn't request a new token and just continues the previous session.@Connor Craig We might be having a bug here, the logout call should have invalidated the auth token, but it seems like even after the logout, the token still works for maintaining the session.
We will file an internal ticket and make a fix for this.
There could be a workaround to fix your case though. Can you update the getAuthToken call to skip returning the old token after you called the logout method?
Hey @jbc ! Thanks for your response. We actually aren't reusing the token (or atleast I assume we aren't, since the
getToken call doesn't happen again after the user is already logged in - note we are using TrustedAuthToken auth). It seems to restart the past session that we had when we originally created the token. We are trying to invalidate that session when the user logs out, but calling the logout REST API endpoint doesn't seem to work for us.Yes logout endpoint should invalidate the session, but it is not. We have created an internal ticket to fix this. @Sandeep / @Anand Pushpraj do we have a workaround for this so that the session gets invalidated?
@Connor Craig Would be able share the snippet related to your init() function? I can check and see if I can suggest a workaround there
logout call will not invalidate the token, it will invalidate cookies if present ,
We cache your token, to avoid multiple unnecessary calls to your endpoint
your can clear the cached token using resetCachedAuthToken
in latests versions of SDK calling init again will remove your token :
@shikharTS @jbc ref PR : https://github.com/thoughtspot/visual-embed-sdk/pull/1103
additionally if you want to invalidate the token :
we have
POST /api/rest/2.0/auth/token/revoke
calling this will invalidate your token ,
take a look here : https://try-everywhere.thoughtspot.cloud/v2/#/everywhere/api/rest/playgroundV2_0?apiResourceId=http%2Fapi-endpoints%2Fauthentication%2Frevoke-tokenHi @Justin Mathew ! I just tried
resetCachedAuthToken and this doesn't work. Once calling that, from an alternate page in the same application (after the liveboard has been initialized already in a separate page, and then destroyed) it doesn't require the user to grab the token again. The page just calls the info endpoint in the Thoughtspot API and then continues the last session.
I did also try the revoke endpoint a couple times without any success, as the token doesn't seem to be utilized any more.
Hey @jbc yes here is my init function:
@Connor Craig I think this might require the TS team to take a look at your code. We have asked the SRE to get on a call with you. We can analyze this further on the call..
Sure thing, one of my coworkers is currently on vacation that I want to attend the meeting with me. He should be back next week if that works for you all 🙂
NP. Just let the TS SRE team know about your preference, we will setup a meeting then
Hey @Justin Mathew ! Nice to meet with you yesterday, we were running into some issues getting the
revoke token endpoint working. When we call it with the token we want to invalidate, the server returns a 204 success. However once we try to use the token, it still works as normal. If we try the validate token endpoint with that same token after revoke, it still returns as a valid token. Any ideas what might be happening here? Please let us know!@Connor Craig can you share the payload you used ?
Sure could I Direct Message you the payload? Just because it contains company tokens
I also put the payload on the community support ticket I have on the Thoughtspot forum
I could also just remove the tokens and paste it here one moment
@shikharTS can you check our BE logs to see what is happening here ?
cc: @pallav
ack. let me check. I need the company name though @Connor Craig
Our company name is Payscale
@shikharTS
@Connor Craig I am having some difficulty in trying to get the logs for the /revoke endpoint. Can you tell me the time you were trying this out? Also, can you follow these steps in the rest api v2 playground on your thoughspot app?
1. Get a token using /auth/token/full - lets call this token1
2. Confirm token1 is correct using /auth/token/validate
3. Revoke token1 using /auth/token/revoke
4. Confirm you have an error when using /auth/token/validate using token1.
The bearer token being used to call these apis and token1 should be different
@shikharTS in our case the token being used to call these apis is the same as the token we are revoking. Should it be different? Do we need to request an additional user token just to revoke a different user token?
I think so, @Sandeep can you confirm this. But @Connor Craig can you try using a different token?
Is there anything in specific that this token needs in terms of permissions? Why does the endpoint (revoke) return a 204 when we request it with the same token? Seems strange
@shikharTS
I don't think this token requires any specific set of permissions. For the 204, let me ask internally and comment here.
As far as I can see with the implementation, even if you use the bearer token and while triggering revoke api use the same bearer token, it will give 204 and then all the subsequent api calls will give you 401 unless you refresh the page (which will generate a new bearer token).
We just tested this using a full administrator token as the bearer token, but still doesn't work. Calling
validate works on that token after initial creation. Once we call revoke then we get a 204 response.
Afterwards, we call validate on that same token and still get a successful response back from the server saying that token is still valid.
This still isn't working for us, where revoke won't actually invalidate the token unfortunately.Tried checking the entire logs and couldn't narrow down the cause of this behaviour. Also as shikhar asked earlier, have you tried using different token?
Yes, we tried using a completely separate token from the one we are revoking. The endpoint still returns a 204
Imagine like this:
Admin Token: abc123
Token we are trying to revoke: xyz987
@Connor Craig do you have orgs enabled? Also can you file a TS support ticket for this? And upload the HAR files when you are trying this out in the playground and a bit more information about your cluster environment.. We do not see any issue in the log files
@shikharTS Yes we have orgs enabled. We can create a ticket next week 🙂
Hey @shikharTS ! Just a heads up, we are going to update the old ticket with our findings 🙂
@Connor Craig have you confirmed that the xyz987 token in the above example is still valid? We might need a call for this and take a look how you are using this or if there is a bug on our end..
Hey @shikharTS ! Yes we tried the
validate endpoint as well to check whether the token was still valid after calling the revoke endpoint (still saying that it is valid) in addition to actually trying the token in Thoughtspot embed itself (still working).One last thing @Connor Craig can you do these steps in TS UI using the rest playground API v2.0?
Already tried that, same result. @shikharTS