Debugging Web Access Token (WAT) Issues with ComposeSDK
Summary: Jeremy Friedel provides a detailed guide for developers encountering issues with Web Access Tokens (WAT) when using ComposeSDK to embed Sisense dashboards and widgets. The discussion covers verifying Sisense licenses, testing token functionality directly through Fusion, validating token claims, and troubleshooting within the ComposeSDK environment. Additionally, alternative authentication methods are suggested if WAT is not available, such as using a bearer token or SSO. The article also encourages contacting a Sisense account representative if WAT needs to be added to a license.
Debugging Web Access Token (WAT) Issues with ComposeSDK
In initial testing, developers embedding Sisense dashboards and widgets with ComposeSDK sometimes find that a Web Access Token (WAT) passed to the SisenseContextProvider component through the wat prop fails to authenticate, and dashboards or widgets do not load. This article describes the steps for isolating the cause, starting with confirming the Sisense license includes WAT at all, then working through the token's own configuration.
Confirm the Sisense license includes WAT
Before debugging the token itself, confirm that the WAT works directly against Fusion, outside of ComposeSDK. Some Sisense licenses do not include WAT as a feature, and a token generated on a server without WAT licensed will not work in ComposeSDK regardless of how it is configured. WAT is also incompatible with the Sisense Multitenancy feature.
Test the token directly against Fusion using the following URL pattern, replacing the placeholders with the organization's Sisense URL, the generated token, and the target dashboard or widget ID:
If this URL returns an error with status code 403 and a message stating that the license is turned off, the Sisense license does not currently include WAT. The organization's Sisense account representative can discuss adding WAT to the agreement. Until WAT is added, see "Use alternative authentication when WAT is not available" below for other options to continue development and testing.
Full documentation on WAT is available on the Using Web Access Tokens page.
Validate the WAT's own claims
If the license includes WAT, confirm the token payload itself is correctly structured before testing in ComposeSDK. These checks apply whether the token is being tested in Fusion, other forms of embedding, or in ComposeSDK.
Confirm the token is valid using the "Test Existing Token" function, described on the Using Web Access Tokens page, in the Sisense Admin panel. This runs structure, logic, and data validation together, so it can catch an invalid "sub" user, theme, or dashboard ID in a single check before working through the items below individually.
Confirm the WAT works when tested directly against Fusion, using the URL pattern from the license section above, if this has not been tested yet. This confirms the token's claims work outside of ComposeSDK before assuming the problem is in the token itself.
Confirm the "sub" claim in the token is a valid, existing user id on the server. The current logged in user's user ID can be retrieved from the browser developer console with:
Confirm the user id in the "sub" claim has access to the relevant data sources.
Confirm any theme id included in the token exists on the server. Theme ids can be checked with the List Themes endpoint in the REST API. As a test, try generating a token with no theme id set.
Confirm the token's start and end unix timestamps are correct, and that the current unix time falls between them. The site unixtimestamp.com can be used to check this.
If dashboard or widget ids are used, confirm those ids are included in the token.
Remove any parameters from the WAT that are not strictly required. The number of required parameters is smaller than what default token generation includes.
Confirm the secret (public key) used matches the token configuration referenced by the "kid" in the token's header. A secret from a different token configuration produces the error "Invalid public key."
If the payload includes large "prm", "res", "flt", or "acl" claims, confirm their combined character count does not exceed 81,200 characters per token. This limit is rarely reached, but can occur with very large permission or filter lists.
Isolate whether the failure is specific to ComposeSDK
If the token work's in Fusion and other form's of Sisense embedding and passes all checks, but WAT still fails only when used through ComposeSDK, and not through Fusion, the cause is likely in the ComposeSDK application itself rather than the token.
Test with a known good token, manually pasted in as a temporary replacement to any variable based structure, to confirm whether the issue is in this particular token or in the surrounding code.
If testing with a dashboard id has not worked, try testing with a ComposeSDK widget defined directly in CSDK code, with no dashboard or widget ID server dependency, to rule out an ID mismatch.
Test on a blank localhost page with a minimal ComposeSDK implementation, to rule out interference from other libraries in the application.
Use alternative authentication when WAT is not available
If the Sisense license does not include WAT, ComposeSDK development and testing can continue using other authentication methods. A viewer role user, or higher, is all that either option requires:
Organizations interested in adding WAT to their license should contact their Sisense account representative.
