Issue with Sisense Compose SDK and SSO Authentication
Hi all!
I am currently facing an issue while trying to visualize data on my dashboard using the Sisense Compose SDK in combination with SSO authentication (auth0). I have followed the guidelines provided in the following article to set up SSO with Auth0: Link to Article: Setting up SSO (SAML 2.0) with Auth0
Despite following the instructions in the article, I am unable to make it work as intended.
Here is the problem I am encountering:
- After successfully logging in to my application, I attempt to load data from Sisense using the SDK
- The SDK redirects me to the Sisense dashboard (because "/api/auth/isauth" responds with not authenticated)
- I am successfully logged into Sisense; however, I cannot access the data from my dashboard
Upon further investigation, I noticed that the issue appears to be related to the browser not sending all the necessary cookies when making the "/api/auth/isauth" request. This request consistently returns "isAuthenticated": false, even though I am logged in.
Best regards, Ziga
ziga
Posted 2 years ago · Edited 2 years ago·Last reply 2 years ago
3 comments
tuan
·2 years agoThere is a feature introduced in L2021.3 that you may want to enable to allow redirects back to the application page. The flag is called newReturnToValidationBehavior, which is accessed from the internal Base Configuration page.
This flag exposes the Allowed Target URLs section in Security settings.
--
Below are steps to get to the internal Base Configuration:
tuan
·2 years agoHi Ziga,
Yesterday we released a minor version of Compose SDK, 0.12.0, which includes a fix for SSO URL /api/auth/isauth. Can you upgrade to that version and get back to me if the issue still persists?
Thanks for using Compose SDK.
Tuan
---
Tuan Pham
Sisense – Staff Software Engineer
ziga
OP2 years agoHi Tuan,
I have tested the new version of the SDK, and there is some progress. It successfully passes the /api/auth/isauth request now. However, I'm encountering issues with any subsequent requests made to the API.
I've checked the failing requests and noticed that the same cookie, which is sent with the /api/auth/isauth request, is being used with the failed requests.
Ziga