search

looker-open-source / embed-sdk

The Looker browser embedding SDK
MIT License
71 stars 46 forks source link

URL encoding issue #87

Open shirblc opened 3 years ago

shirblc commented 3 years ago

We're using the SDK to display Looker reports in our platform, but we've disabled Looker's built-in filters and we're using our own filters. So instead of using the SDK's filters, we pass filters in via the embed URL, like: embed/dashboards-next/5?embed_domain=http://localhost:8081&sdk=2&Strategy=strategy-name&Date=2021-08-04+to+2021-08-06

It works for everything except in case there are special characters in the URL, like &. The issue is, despite our server encoding this &Date=2021-08-04 to 2021-08-06&Strategy=strategy & tactics correctly into &Date=2021-08-04+to+2021-08-06&Strategy=strategy+%26+tactics, it would appear the embed SDK is turning it back into &, which makes it think the rest of it is a separate query param. We've followed it from our API to the our front-end, all the way to this method which uses the SDK (I've shortened it to the used bit, the rest isn't used in our code at the moment):

function builderFor(url: string) {
  return LookerEmbedSDK.createDashboardWithUrl(url);
}

The URL showing there is still the correctly-encoded URL, which made us think it might not be an issue in our code. We've also looked into the network requests to our Looker domain include encoded and decoded URLs - it seems that the SDK is sending both, but the ones there's a response to are the decoded ones, and because it's completely decoded, the & shows up as & rather than %26, which explains the issue we're having.

We're struggling to debug the SDK itself, but the Looker embed SDK is responsible for interacting with the Looker server, which makes us think there might be an issue in how the SDK handles special characters. Can you help?

fabio-looker commented 2 years ago

I can't fully tell from your description, but one possibility is that there may be a missing level of encoding? The signed URL, which is what you should be passing in to the createDashboardWithUrl method, itself includes the target URL the user needs to be sent to. Since this target/redirect URL itself a parameter within the authentication request URL, it should be encoded (causing the % sign in the already encoded filter value to be encoded once again)