alc-aaron - Hi all, I was hoping someone could ...
Hi all, I was hoping someone could explain the following EmbedConfig option?
Could someone give an example of how the full app could be accessed with this option turned false versus true?
Solution:Jump to solution
It is possible that if someone clicks on a link in the iframe which opens a TS url, they can see the non embed ThoughtSpot UI. With this option as true, they will be blocked from seeing the non embed TS UI. cc @Ruchi Anand
7 Replies
Solution
It is possible that if someone clicks on a link in the iframe which opens a TS url, they can see the non embed ThoughtSpot UI. With this option as true, they will be blocked from seeing the non embed TS UI. cc @Ruchi Anand
Thank you!
If you use customizations though (say for strings to whitelabel Spotter), wouldn't these still be representing a non-embed version of these strings if you click a link with blockNonEmbedFullAppAccess=true?
So using customizations is completely on embed. Are you talking about the strings in the link?
I'm saying if you use thoughtspot as an embed experience, any string customizations would not be honored if users used 'Copy Link' and opened those in a new tab. Even if
blockNonEmbedFullAppAccess
is trueIf blockNonEmbedFullAppAccess is true, it will not let the users open the link in a new tab. But yes, if the end users are able to open the ThoughtSpot UI in a new tab, the string customizations would not be honoured since they are completely within the context of the ThoughtSpot embedded SDK..
@seansy-archy we recommend avoiding the use of this SDK flag as it will be deprecated in an upcoming release. for enhanced security, if you need this functionality, we suggest implementing it via 'Security Settings'. you can find more details here: https://developers.thoughtspot.com/docs/selective-user-access#block
User access to non-embedded content
Selective user access for TSE customers