QQ - what triggers `AuthFailureType.

QQ - what triggers AuthFailureType.OTHER to be sent from the embed SDK? We are seeing an uptick in frequency and would like to understand root cause and how we can better manage these events
22 Replies
priyanshu.kumar
priyanshu.kumar3mo ago
Hi @Leslie Chiang, AuthFailureType.OTHER gets triggered when we are using AuthType.TrustedAuthTokenCookieless and the call for getting a new Authentication Token fails.
Leslie Chiang
Leslie ChiangOP3mo ago
Thanks @priyanshu.kumar ! How about for AuthType.TrustedAuthToken? We have autoLogin set to true, but do we expect this event to occur first, and then for the SDK to try to authenticate?
priyanshu.kumar
priyanshu.kumar3mo ago
Hi @Leslie Chiang I don't see AuthFailureType.OTHER getting triggered for AuthType.TrustedAuthToken. If its getting triggered for you can you please tell which version of sdk are you using. I will be able to check better.
Leslie Chiang
Leslie ChiangOP3mo ago
Thank you for checking, we are using 1.33.0 . When using TrustedAuthToken, we get the AuthFailureType.OTHER after about an hour of inactivity. @priyanshu.kumar - what can be done to help us understand the changes that need to be made in order to reduce the number of auth errors? Can we schedule some time to troubleshoot in real time? Would traceIds of the failing session/info calls help?
utsav.kapoor
utsav.kapoor3mo ago
@Leslie Chiang - Will schedule a call for this. In the meantime @Justin Mathew can respond to this thread To answer the question: 1. AuthFailureType.OTHER is triggered for both AuthType.TrustedAuthToken as well as AuthType.TrustedAuthTokenCookieless 2. AuthFailureType.OTHER is sent when Authentication fails with Thoughtspot. This generally results when a user session has expired. Can you please tell me what is the token validity you have set ? 3. HAR File that you shared has a session expiry coming from isActive API. Can you confirm if you have set values for authenticatedIdleTimeoutMs and if they are lower than Token validity ? In the meantime, Ill get a call setup for this ASAP so we can discuss more. @Justin Mathew @shikharTS - FYI
Leslie Chiang
Leslie ChiangOP3mo ago
Thank you for following up! Token validity we have tested increasing to 60 hours, and it still gives us an error in ~1 hour. 3) We have not set authenticatedIdleTimeoutMs - is this something we should set to override? Can we remove the Idle timeout completely and just rely on token validity and automatic retry when no longer idle?
utsav.kapoor
utsav.kapoor3mo ago
authenticatedIdleTimeoutMs has a default value which is around 1-3 hour depending upon the cluster. The flag is a security flag. We can increase that value to unblock you. I am also working on aligning such configs to Token expiry. Will come back on this tomorrow. I have asked for a call and we can go through this , ill check a few things tomorrow PST
Leslie Chiang
Leslie ChiangOP3mo ago
Okay, thank you - I will check in with my team to see what value we might want to increase the idle timeout to. I think that will reduce the impact the timeout is having, we would likely still want to understand how we should configure the embed to gracefully recover once the user is active again, instead of keeping the authentication error message up
utsav.kapoor
utsav.kapoor3mo ago
Yes that is what I am working on.
Justin Mathew
Justin Mathew3mo ago
@Leslie Chiang We do provide an param loginFailedMessage which is shown on screen such cases. It takes html sting as well, so you can have custom buttons / reload flows setup on your end. @Leslie Chiang you've mentioned that you are seeing an uptick in these events, wanted some details for regarding this is it always due to an idile session being kept for more than an hour ? if possible an har would be helpfull where there are multiple failures. Since you are using AuthType.TrustedAuthToken your session should not be expired since its in cookies, other than authenticatedIdleTimeoutMs case which @utsav.kapoor mentioned , we will update here once any udpate ps : AuthFailureType.OTHER is sent in all auth types in case of an unsuccessful login , it is also sent in case of Cookieless where the token function was errored out
Leslie Chiang
Leslie ChiangOP3mo ago
Thank you @Justin Mathew - I'll look into the reload suggestion. Is there a way send a HostEvent to trigger auth again, or would this require reloading the Embed component? For the uptick, this is just based on user feedback - people are complaining more and more that they are running into the loginFailedMessage; we have not beeing logging this event continuously so can't verify with numbers I just saw there is a HostEvent.Reload event - will this trigger auth to help the user recover or do we need a full re-render of the component? ty!
Justin Mathew
Justin Mathew3mo ago
that should be enough
Leslie Chiang
Leslie ChiangOP3mo ago
Okay, thank you! One last question, though I think I can work around this - the type of loginFailedMessage is string - would i put quotes around to convert any JSX into a string? Can you confirm if it will render a ReactNode?
Justin Mathew
Justin Mathew3mo ago
no no i wont render a ReactNode , it takes plain html as string we do something like containerEl.innerHTML = loginFailedMessage; this
utsav.kapoor
utsav.kapoor3mo ago
@Leslie Chiang - I have also asked our SRE team to reach out so we can also have a call to understand a few things and go over this. While you are unblocked but we do want to go over a few things so we can have a better long term solution
Leslie Chiang
Leslie ChiangOP3mo ago
Okay, thank you both! I will continue to test out different approaches from our side and look forward to the call
utsav.kapoor
utsav.kapoor3mo ago
Sure @Leslie Chiang - I have pinged the CSM to put a meeting in the 1st week of December as both me and the PM team is Out of Office.
Justin Mathew
Justin Mathew3mo ago
@Leslie Chiang i got why you were facing that issue you are trying to render even before init has happned , so make sure rendering is done after init
Leslie Chiang
Leslie ChiangOP3mo ago
@Justin Mathew I'm not sure that's the case - we do keep state if TS is initialized and only render if initialized (after we get the login success event). For idle timeout, I tried resetting state to not initialized (removing the rendered embed) when the timeout starts occurring, but every attempt to reinitialize fails afterwards @Justin Mathew @utsav.kapoor - can we increase the idle timeout to the max for now (3 hours?) We'd like to at least decrease the frequency users are running into this issue in the near term, since our workaround attempt did not successfully resolve the issue and we are waiting until after the holidays to have a meeting.
shikharTS
shikharTS2mo ago
cc @Aditya @utsav.kapoor
utsav.kapoor
utsav.kapoor2mo ago
@Leslie Chiang - Can you send me the ticket number for this ? I can use it to setup a call.
Leslie Chiang
Leslie ChiangOP2mo ago
Hi @utsav.kapoor - ticket number is 00377875 I also see that you are in the #cust_spotnana_ext Slack channel - feel free to communicate there as I check messages there more frequently

Did you find this page helpful?