TrustedAuthTokenCookieless and JIT
TrustedAuthTokenCookieless and JIT provisioning can be used in conjunction right?
17 Replies
yes
The infrastructure for a setup like that would ideally live on the server and not the client right?
JIT provisioning happens through the /token API (this can exist in both server and client). TrustedAuthTokenCookieless is an auth scheme in SDK(which is typically written in client). you call the /token API with it. So go with whatever design suits. your app..
thanks brother
Yes, @ThatSpot, we recommend setting up the init block on the server side. This prevents the cluster secret key from being exposed in the network tab of the browser console.
Can you go into detail about an implementation like that? We would return the init object from the server?
@ThatSpot No, init can only be done at the client side.
The setup you can implement though:
// Keep this in your backend server
/getTokenForUser
API call to /api/rest/2.0/auth/token/full with SECRET_KEY and the JIT parameters.
This returns single login token.
// Client
init({
thoughtSpotHost: "https://<hostname>:<port>",
authType: AuthType.TrustedAuthTokenCookieless,
getAuthToken: () => {
return fetch('/getTokenForUser'); // Call your server implementation
}
});
Good news bad news. Good news we're doing this. Bad news it doesn't work currently.
@ThatSpot can you try these options and let us know the results:
1. Can you delete the cookie and use useLocalStorageForMixpanel: true URL Flag in your init using this. t. This is the flag we use to disable Cookies for Mixpanel and switch to localStorage. Please only do this for dev purposes. https://developers.thoughtspot.com/docs/Interface_EmbedConfig#_additionalflags
2. Can you also turn this flag true in your init config https://developers.thoughtspot.com/docs/Interface_EmbedConfig#_disablesdktracking ? cc @utsav.kapoor @jbc
EmbedConfig
The configuration object for embedding ThoughtSpot content. It includes the ThoughtSpot hostname or IP address, the type of authentication, and the authentication endpoint if a trusted authentication server is used.
no luck
Wait it looks like that may have worked. It doesn't really help us in terms of getting us to production but it's a step forwards!
@ThisSpot this is the thread
@ThatSpot why does it not help of getting to production? Is there any other issue you have?
For production instances, you will not get this error @ThatSpot , since it is the AWS WAF rules being invoked due to cookies with referring domain as localhost..
oh that makes sense! Thanks @shikharTS. So I should be able to disable this in non-local environments?
yes
okay thank you brother
y'all are the best c: