Sindhu Shanmugam - Hi , we are facing a Embed S...
Hi , we are facing a Embed SDK issue , AuthStatus.SUCCESS is not triggered. The callosum/v1/session/info endpoint is returning a 401 Unauthorized error when triggered from within the ThoughtSpot module. This prevents the Success event emitter in the init callback function from being triggered, causing the metadata search API call to fail. However, when the callosum/v1/session/info API is called directly from the code, it returns a valid response.
17 Replies
Hey, can you confirm the understanding -
1. You are using visual-embed-sdk for init and then getting 401 and also after that your - call metadata/search api is failing anyways.
2. But when you do call - v1/session/info - from your code then the api call after that works fine?
- If that's what the info is :
1. Hey one failed info call is expected. - are the calls subsequent to that are faliing all?
- Can you confirm what is the error for the metadata search api call - response - or error.
2. /v1/session/info - is getting valid response - meaning it's authenticated.
Hi , 1. You are using visual-embed-sdk for init and then getting 401 and also after that your - call metadata/search api is failing anyways. : Yes, using "@thoughtspot/visual-embed-sdk": "1.32.3-alpha-1",
2. But when you do call - v1/session/info - from your code then the api call after that works fine? Yes
If that's what the info is : ?
* Hey one failed info call is expected. - are the calls subsequent to that are faliing all?: Yes, all the calls are failing, even if I try to call "getSessionInfo" , thats also failing.
* Can you confirm what is the error for the metadata search api call - response - or error. : error 401
HTML
"error": {
"message": {
"debug": "Unauthorized: The client must authenticate itself to get the requested response."
}
}
* /v1/session/info - is getting valid response - meaning it's authenticated. : 401 for this also (triggered from within the thoughtspot package 'tokenizedFetch.ts')
HTML
<html>
<head>
<link rel="stylesheet" type="text/css" href="/generic.css">
<script>
/**
* This file can simply be linked as error_code.html in the same directory
* to generate an error code page.
*/
var errorCode = 401;
var title = "Unauthorized";
var desc = "The client must authenticate itself to get the requested response.";
window.addEventListener('DOMContentLoaded', (event) => {
document.getElementById("code").innerText = errorCode;
document.getElementById("message").innerText = title;
document.getElementById("desc").innerText = desc;
});
</script>
</head>
<body class="body-background-grey">
<div class="invalid-page-content">
<div class="pack-vertical" alt="Error">
<div class="ts-logo-wide"></div>
<div class="msg-row">
<div id="code" class="big-code"></div>
<div id="message" class="error-msg">Invalid code.</div>
</div>
<div id="desc">Invalid Error Code</div>
<a href="/" class="invalid-page-home-btn">Back to home</a>
</div>
</div>
</body>
</html>
Adding in @MuditManucha who is our developer
@yuichirio_ha can you please help with this
CC : @jbc
@Sindhu Shanmugam Attached is an example that I have that is working. It makes a metadata/search call prior to rendering anything. The key is that you need to use SDK_Success. Success isn't sent until you render something (based on my testing). Let me know if you have questions.
Please find the attachment code snippet for meta data fetch and init functions.
Thanks @MuditManucha. It's not clear in the metadata.js file how the
Also, instead of using
isAuthenticated values is being set. I notice that you are still listening for the AuthStatus.SUCCESS. You should listen for the AuthStatus.SDK_SUCCESS.Also, instead of using
fetch use tokenizedFetch from the SDK (just import and use like fetch. See the following example:
const response = await tokenizedFetch(
tsURL + "/api/rest/2.0/metadata/search",
{
method: "POST",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
type: "LIVEBOARD",
}),
}
);const embedConfig = {
thoughtSpotHost: "https://tlcmarketing-prod.thoughtspot.cloud",
authType: AuthType.EmbeddedSSO,
//customCssUrl: "cdn.jsdelivr.net/gh/robereng/override@main/override.css",
ignoreNoCookieAccess: true,
disableLoginFailurePage: true
}
let authStatus = init(embedConfig);
authStatus.on(AuthStatus.FAILURE, (reason) => {
console.log('Authentication failed');
console.log(reason);
logout();
});
authStatus.on(AuthStatus.SUCCESS, () => {
console.log('Authentication success');
});
authStatus.on(AuthStatus.SDK_SUCCESS, () => {
console.log('Authentication SDK success');
});
I am not sure how but AuthStatus.SDK_SUCCESS gets triggered even though I had not logged in to azure also.
You can ignor isAuthenticated as that is for Azure authentication check
@bill_da_golfer is there a way if we can identify why exactly
https://tlcmarketing-prod.thoughtspot.cloud/callosum/v1/session/info is giving 403, I feel this is the actual root cause
@bill_da_golfer tokenizedFetch also didnt help much, same results
I'll try to see if I can get an SSO environment to test against to at least try to replicate.
Depending on when in the process, it's natural for the
It's likely we'll need to set up a working session to try to walk through your code and make some changes live to test. It's a little hard to completely replicate the issue on my side.
session/info to fail. It's used to check if you are logged in. So it depends on when it's being called in the flow.It's likely we'll need to set up a working session to try to walk through your code and make some changes live to test. It's a little hard to completely replicate the issue on my side.
@bill_da_golfer just to bring in some more clarity
callosum/v1/session/info gives success if triggered directly from code but errors out in case if it is been triggered from Thougtspot SDK
Can we check the payload of the
info calls to check if there is any difference ?@bill_da_golfer It sounds like Mudit has come up with a workaround, but it's taking more time than expected to embed . It would be great if we could arrange a working session to go over the process together, try to optimize it, or find ways to make it more efficient.
Hi Ashish , we'll come back to you on this
Seems its exactly same, just the initiator difference
Yeah, it would probably be good to meet at this point. I'm trying to get a cluster with SSO, but that's taking some time. I have some availability today and tomorrow.
OK, I have an SSO example and am getting failures if the SSO auth fails. Trying to get some feedback internally for options.
Thanks Bill 🙂