-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Embedded SDK #18250
feat: Embedded SDK #18250
Changes from 12 commits
5f2bbfa
c021559
399437b
c2113d7
ff69ca7
61380bf
1a69603
aadd3b2
b574767
3e6e660
ed9dcf9
e023db3
75c80c0
3f9ca83
5efa6ee
9ac5b66
90f78bf
27006c0
e71f750
8b2c8ef
274a5cb
be462f7
5475088
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
name: release-embedded-sdk-workflow | ||
|
||
on: | ||
push: | ||
branches: | ||
- 'master' | ||
|
||
jobs: | ||
build: | ||
name: Build and publish the embedded sdk if version changed | ||
|
||
runs-on: ubuntu-20.04 | ||
|
||
strategy: | ||
matrix: | ||
node-version: [16] | ||
|
||
steps: | ||
- name: Use Node.js ${{ matrix.node-version }} | ||
uses: actions/setup-node@v1 | ||
with: | ||
node-version: ${{ matrix.node-version }} | ||
registry-url: https://registry.npmjs.org/ | ||
|
||
- name: Cache npm | ||
uses: actions/cache@v1 | ||
with: | ||
path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS | ||
key: ${{ runner.OS }}-node-${{ hashFiles('**/package-lock.json') }} | ||
restore-keys: | | ||
${{ runner.OS }}-node- | ||
${{ runner.OS }}- | ||
|
||
- name: Get npm cache directory path | ||
id: npm-cache-dir-path | ||
run: echo "::set-output name=dir::$(npm config get cache)" | ||
- name: Cache npm | ||
uses: actions/cache@v1 | ||
id: npm-cache # use this to check for `cache-hit` (`steps.npm-cache.outputs.cache-hit != 'true'`) | ||
with: | ||
path: ${{ steps.npm-cache-dir-path.outputs.dir }} | ||
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} | ||
restore-keys: | | ||
${{ runner.os }}-npm- | ||
|
||
- name: Configure npm | ||
run: | | ||
echo "@superset-ui:registry=https://registry.npmjs.org/" > .npmrc | ||
echo "registry=https://registry.npmjs.org/" >> .npmrc | ||
echo "//registry.npmjs.org/:_authToken=\${NPM_TOKEN}" >> $HOME/.npmrc 2> /dev/null | ||
npm whoami | ||
env: | ||
NPM_TOKEN: ${{ secrets.NPM_TOKEN }} | ||
|
||
- name: Install dependencies | ||
working-directory: ./superset-embedded-sdk | ||
run: npm ci | ||
|
||
- name: Build packages | ||
working-directory: ./superset-embedded-sdk | ||
run: npm run ci:release |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
bundle | ||
dist | ||
lib | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
<!-- | ||
Licensed to the Apache Software Foundation (ASF) under one | ||
or more contributor license agreements. See the NOTICE file | ||
distributed with this work for additional information | ||
regarding copyright ownership. The ASF licenses this file | ||
to you under the Apache License, Version 2.0 (the | ||
"License"); you may not use this file except in compliance | ||
with the License. You may obtain a copy of the License at | ||
|
||
http://www.apache.org/licenses/LICENSE-2.0 | ||
|
||
Unless required by applicable law or agreed to in writing, | ||
software distributed under the License is distributed on an | ||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
KIND, either express or implied. See the License for the | ||
specific language governing permissions and limitations | ||
under the License. | ||
--> | ||
|
||
# Contributing to the Superset Embedded SDK | ||
|
||
The superset-embedded-sdk directory is a self contained sub-project in the Superset codebase. | ||
|
||
This is because the SDK has different requirements from other parts of the Superset codebase: | ||
Namely, we need to export a lightweight frontend library that can be used in as many environments as possible. | ||
Having separate configs allows for better separation of concerns and allows the SDK code to remain simple. | ||
|
||
## Building | ||
|
||
The library is built in two modes: one for consumption by package managers | ||
and subsequent build systems, and one for consumption directly by a web browser. | ||
|
||
Babel is used to build the sdk into a relatively modern js package in the `lib` directory. | ||
This is used by consumers who install the embedded sdk via npm, yarn, or other package manager. | ||
|
||
Webpack is used to bundle the `bundle` directory, | ||
for use directly in the browser with no build step e.g. when importing via unpkg. | ||
|
||
Typescript outputs type definition files to the `dist` directory. | ||
|
||
Which of these outputs is used by the library consumer is determined by our package.json's `main`, `module`, and `types` fields. | ||
|
||
## Testing | ||
|
||
You may notice a lack of tests in this directory. The functions used in the sdk so far are very closely tied to browser behavior, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure about this. It would be really cool if we could spend more time trying to use Jest/JSDOM to write tests that check for specific conditions like:
You could use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, I think you're right that it would be good to unit test the I'll also add an "on pull request" github action that makes sure the build can still run. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there are valid test cases for this code and some of the test cases can even introduce If a user passes an unknown dashboard id like one from a deleted dashboard, what happens when this piece of code executes?
If the user passes an invalid
For both scenarios, are we going to display the default browser error or a custom message inside the iframe? if we chose to display a custom message, the test cases could account for that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For case 1, the SDK does not have any clue that the id doesn't exist. All it does is create an iframe and send a guest token to it. If we want to display some special message in that case, that would happen on the superset side, not in the SDK. In the second case, what happens is entirely dependent on browser implementation. Some browsers could throw an error, which would be fine imo since the caller passed in the wrong thing it should probably throw anyway. But some browsers silently ignore the message, I believe this is to prevent a malicious page from gathering info about other pages. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the case a browser silently ignores the message, won't this line fail later?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It will fail to actually convey the guest token to its intended recipient since no one is listening on the other side, but it won't throw an error. The message channel and port do exist, they're just not connected to anything. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wrote a test for "it doesn't blow up", but actually jsdom doesn't seem to support the iframe's Unless someone knows of a good way around that, I think I'll forego unit testing in favor of thorough cypress testing using the demo host app, which should be added soon. That way we can make actual assertions about the behaviors and security characteristics of this system. For now, this code has been manually tested pretty thoroughly in a couple of applications, and we're focused on getting it usable asap. |
||
and are not easily testable. We have instead opted to test the sdk behavior using end-to-end tests. | ||
This way, the tests can assert that the sdk actually mounts the iframe and communicates with it correctly. | ||
|
||
At time of writing, these tests are not written yet, because we haven't yet put together the demo app that they will leverage. | ||
|
||
## Publishing | ||
|
||
To publish a new version, first determine whether it will be a major/minor/patch version according to [semver rules](https://semver.org/). | ||
Run `npm version [major|minor|patch]`, and commit the resulting version change. | ||
|
||
Building the package and publishing to npm will be handled by github actions automatically on merge to master, | ||
provided that the currently specified package version isn't already published. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
<!-- | ||
Licensed to the Apache Software Foundation (ASF) under one | ||
or more contributor license agreements. See the NOTICE file | ||
distributed with this work for additional information | ||
regarding copyright ownership. The ASF licenses this file | ||
to you under the Apache License, Version 2.0 (the | ||
"License"); you may not use this file except in compliance | ||
with the License. You may obtain a copy of the License at | ||
|
||
http://www.apache.org/licenses/LICENSE-2.0 | ||
|
||
Unless required by applicable law or agreed to in writing, | ||
software distributed under the License is distributed on an | ||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
KIND, either express or implied. See the License for the | ||
specific language governing permissions and limitations | ||
under the License. | ||
--> | ||
|
||
# Superset Embedded SDK | ||
|
||
The Embedded SDK allows you to embed dashboards from Superset into your own app, | ||
using your app's authentication. | ||
|
||
Embedding is done by inserting an iframe, containing a Superset page, into the host application. | ||
|
||
## Embedding a Dashboard | ||
|
||
Using npm: | ||
|
||
```sh | ||
npm install --save @superset-ui/embedded-sdk | ||
``` | ||
|
||
```js | ||
import { embedDashboard } from "@superset-ui/embedded-sdk"; | ||
|
||
embedDashboard({ | ||
id: "abc123", // given by the Superset embedding UI | ||
supersetDomain: "https://superset.example.com", | ||
mountPoint: document.getElementById("my-superset-container"), // any html element that can contain an iframe | ||
fetchGuestToken: () => fetchGuestTokenFromBackend(), | ||
}); | ||
``` | ||
|
||
You can also load the Embedded SDK from a CDN. The SDK will be available as `supersetEmbeddedSdk` globally: | ||
|
||
```html | ||
<script src="https://unpkg.com/@superset-ui/embedded-sdk"></script> | ||
|
||
<script> | ||
supersetEmbeddedSdk.embedDashboard({ | ||
// ... here you supply the same parameters as in the example above | ||
}); | ||
</script> | ||
``` | ||
|
||
## Authentication/Authorization with Guest Tokens | ||
|
||
Embedded resources use a special auth token called a Guest Token to grant Superset access to your users, | ||
without requiring your users to log in to Superset directly. Your backend must create a Guest Token | ||
by requesting Superset's `POST /security/guest_token` endpoint, and pass that guest token to your frontend. | ||
|
||
The Embedding SDK takes the guest token and use it to embed a dashboard. | ||
|
||
### Creating a Guest Token | ||
|
||
From the backend, http `POST` to `/security/guest_token` with some parameters to define what the guest token will grant access to. | ||
Guest tokens can have Row Level Security rules which filter data for the user carrying the token. | ||
|
||
The agent making the `POST` request must be authenticated with the `can_grant_guest_token` permission. | ||
|
||
Example `POST /security/guest_token` payload: | ||
|
||
```json | ||
{ | ||
"user": { | ||
"username": "stan_lee", | ||
"first_name": "Stan", | ||
"last_name": "Lee" | ||
}, | ||
"resources": [{ | ||
"type": "dashboard", | ||
"id": "abc123" | ||
}], | ||
"rls": [ | ||
{ "clause": "publisher = 'Nintendo'" } | ||
] | ||
} | ||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
/* | ||
* Licensed to the Apache Software Foundation (ASF) under one | ||
* or more contributor license agreements. See the NOTICE file | ||
* distributed with this work for additional information | ||
* regarding copyright ownership. The ASF licenses this file | ||
* to you under the Apache License, Version 2.0 (the | ||
* "License"); you may not use this file except in compliance | ||
* with the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, | ||
* software distributed under the License is distributed on an | ||
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
* KIND, either express or implied. See the License for the | ||
* specific language governing permissions and limitations | ||
* under the License. | ||
*/ | ||
|
||
module.exports = { | ||
presets: [ | ||
"@babel/preset-typescript", | ||
"@babel/preset-env" | ||
], | ||
sourceMaps: true, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any need to add
node_modules
or other typical cruft here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nah, the root .gitignore file also applies here