Skip to content
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

Copy assets from appropriate directory for kbn-monaco #178669

Merged
merged 8 commits into from
Mar 21, 2024

Conversation

eokoneyo
Copy link
Contributor

@eokoneyo eokoneyo commented Mar 13, 2024

Summary

Closes #178448

Per the configuration in kibana, Monaco by default will attempt to load the specific worker for each language using the public path record defined on window.__kbnPublicPath__ see here but an error occurs whilst attempting to request the script at the url we expect it to be at because it doesn't exist there, as seen here;
Screenshot 2024-03-13 at 17 21 36

Ideally this works but with the current setup for CDN assets it doesn't map 1:1 to how the assets are expected, we should be copying from the directory target_workers to match the same definition for building packages
, similar to what we have here which is what this PR introduces.

The hypothesis above is verifiable by attempting to request the same resource on the same build of the deployment where the error is reported, with the target_workers path prepended, like so https://kibana.estccdn.com/552e8adcca05/bundles/kbn-monaco/target_workers/json.editor.worker.js we get the file.

@eokoneyo eokoneyo added release_note:skip Skip the PR/issue when compiling release notes Team:SharedUX Team label for AppEx-SharedUX (formerly Global Experience) ci:project-deploy-observability Create an Observability project labels Mar 13, 2024
@eokoneyo eokoneyo self-assigned this Mar 13, 2024
@eokoneyo eokoneyo requested a review from a team as a code owner March 13, 2024 18:23
@elasticmachine
Copy link
Contributor

Pinging @elastic/appex-sharedux (Team:SharedUX)

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I like this approach and I think it solves the non-origin Worker loading problem comprehensively.

Tested locally with CDN assets built being served from another domain and LGTM! Great work @eokoneyo

package.json Outdated
@@ -1096,6 +1096,7 @@
"remark-gfm": "1.0.0",
"remark-parse-no-trim": "^8.0.4",
"remark-stringify": "^8.0.3",
"remote-web-worker": "^0.0.9",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a weird quirk that setting worker-src (as we are doing) still does not fix this issue...

I was exploring a fix here but I think patching the global worker object may be the best way to ensure this doesn't trip up other devs. I think we should get @elastic/kibana-security eyes on this too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW in my local testing these were my CSP response headers:

script-src 'report-sample' 'self' 0719-85-145-78-244.ngrok-free.app; worker-src 'report-sample' 'self' blob: script-src 'report-sample' 'self' 0719-85-145-78-244.ngrok-free.app; worker-src 'report-sample' 'self' blob: 0719-85-145-78-244.ngrok-free.app; style-src 'report-sample' 'self' 'unsafe-inline' 0719-85-145-78-244.ngrok-free.app; connect-src 'self' *.elastic.co 0719-85-145-78-244.ngrok-free.app; font-src 'self' 0719-85-145-78-244.ngrok-free.app; img-src 'self' *.elastic.co data: 0719-85-145-78-244.ngrok-free.app; style-src 'report-sample' 'self' 'unsafe-inline' 0719-85-145-78-244.ngrok-free.app; connect-src 'self' *.elastic.co 0719-85-145-78-244.ngrok-free.app; font-src 'self' 0719-85-145-78-244.ngrok-free.app; img-src 'self' *.elastic.co data: 0719-85-145-78-244.ngrok-free.app

I was serving assets via ngrok to check how it plays over https too. As you can see worker-src includes 0719-85-145-78-244.ngrok-free.app 🤷🏻

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And it looks like we still need to fix Console's worker loading

Screenshot 2024-03-14 at 17 36 42

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it also caught me by surprise, I'm of the same opinion that we make the patch global so everyone gets it for free moving forward. I'll be pushing a update to this that's close to what you had but mostly builds of this library with an extra conditional to account for how ace editor workers get loaded.

@jloleysens jloleysens requested a review from a team March 14, 2024 16:30
@kc13greiner kc13greiner self-requested a review March 14, 2024 16:45
@jbudz jbudz self-requested a review March 14, 2024 16:51
Copy link
Member

@dmlemeshko dmlemeshko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kbn-test changes lgtm

@kc13greiner
Copy link
Contributor

Heya @eokoneyo ! A couple QQ to help with my understanding:

Ideally this works but with the current setup for CDN assets it doesn't map 1:1 to how the assets are expected

  • I wasn't sure what this meant; Im not too familiar with the other CDN work going on 😅. Can you explain further?

  • Is this PR a temporary fix?

    • If not, are there any other options than patching every worker to allow this?
    • Are the URLs known? Maybe it could be limited to a subset of URLs?
    • Could the patch be moved down into kbn-monaco or where the workers are spawned?

@eokoneyo
Copy link
Contributor Author

Hi @kc13greiner!

Heya @eokoneyo ! A couple QQ to help with my understanding:

Ideally this works but with the current setup for CDN assets it doesn't map 1:1 to how the assets are expected

  • I wasn't sure what this meant; Im not too familiar with the other CDN work going on 😅. Can you explain further?

Sure, kibana packages it's assets so its reference for assets points to the host machine that runs it, but with Serverless that didn't scale well (for example there were cases of missing chunks because a open tab still refers to assets from a previous deployment that doesn't exist again). The CDN work makes it so that the aforementioned example issue doesn't occur.
On how this pertains to this PR, the change makes it such that when retrieving the assets for monaco's workers the same directory structure that gets emitted on build is preserved so that the method provided to monaco that fetches the workers it requires simple works as is.

  • Is this PR a temporary fix?
    • If not, are there any other options than patching every worker to allow this?
    • Are the URLs known? Maybe it could be limited to a subset of URLs?
    • Could the patch be moved down into kbn-monaco or where the workers are spawned?

As of now this is the most promising approach to circumvent the issue (the issue being that the worker constructor would only execute scripts that obey same-origin policy), and for what it's worth the reason we can't opt for a specific fix that doesn't patch the worker global is because we'd have to patch monaco itself.

@kc13greiner
Copy link
Contributor

Sure, kibana packages it's assets so its reference for assets points to the host machine that runs it, but with Serverless that didn't scale well (for example there were cases of missing chunks because a open tab still refers to assets from a previous deployment that doesn't exist again). The CDN work makes it so that the aforementioned example issue doesn't occur. On how this pertains to this PR, the change makes it such that when retrieving the assets for monaco's workers the same directory structure that gets emitted on build is preserved so that the method provided to monaco that fetches the workers it requires simple works as is.

Thank you for the detailed response 🚀

As of now this is the most promising approach to circumvent the issue (the issue being that the worker constructor would only execute scripts that obey same-origin policy), and for what it's worth the reason we can't opt for a specific fix that doesn't patch the worker global is because we'd have to patch monaco itself.

What other approaches were considered? Allowing all workers to circumvent the CSP definitely raises security concerns; is there any other way we could approach this that wouldn't be so global or could limit the impact?

@jloleysens
Copy link
Contributor

jloleysens commented Mar 19, 2024

@kc13greiner in this case we have set worker-src but it seems this directive still does not allow workers to be instantiated with scripts on remote domains. https://developer.mozilla.org/en-US/docs/Web/API/Worker

In this case the workaround is still constrained by connect-src script-src that governsimportScripts. I was hoping to get a sanity check on our use of worker src and whether there are any other issues with this approach. Unfortunately I don't know of another solution than what @eokoneyo has proposed.

@kc13greiner
Copy link
Contributor

@eokoneyo @jloleysens ++ I see what you're getting at now - I'm still looking into it and discussing it with the team.

@jloleysens jloleysens added ci:project-deploy-elasticsearch Create an Elasticsearch Serverless project and removed ci:project-deploy-elasticsearch Create an Elasticsearch Serverless project labels Mar 20, 2024
Copy link
Contributor

@kc13greiner kc13greiner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM - a couple question/nit!

The Workers will still be subject to the CSPs script-src directive since they are using importscripts.

Creating Workers with scripts from remote origins does appear to be a wider issue.

packages/kbn-ui-shared-deps-src/src/polyfills.js Outdated Show resolved Hide resolved
super(
// Check if the URL is remote
url.includes('://') && !url.startsWith(window.location.origin) && !url.startsWith('blob:') // to bootstrap the actual script to work around the same origin policy.
? URL.createObjectURL(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observation/nit: Im not sure how severe is, but I think this may have a small memory leak - seems low impact, just something to keep in mind!

Copy link
Contributor

@kc13greiner kc13greiner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@kibana-ci
Copy link
Collaborator

kibana-ci commented Mar 21, 2024

💚 Build Succeeded

Metrics [docs]

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id before after diff
module count - 5806 +5806
total size - 6.5MB +6.5MB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
kbnUiSharedDeps-srcJs 2.9MB 2.9MB +469.0B
Unknown metric groups

ESLint disabled line counts

id before after diff
@kbn/ui-shared-deps-src 2 3 +1

Total ESLint disabled count

id before after diff
@kbn/ui-shared-deps-src 2 3 +1

History

  • 💔 Build #198705 failed 97cf3c0382b3b2f9002e7625b96f45d8168d9b44
  • 💚 Build #198655 succeeded 7d42074f4f4318b47696f58d57b348bbbe5d4e85
  • 💚 Build #198634 succeeded 9f786df61b4e0dcb1cca333fe09759422a915ad9
  • 💛 Build #198251 was flaky 889dff5a0998b12f2f347969e1a056581072051b
  • 💚 Build #197761 succeeded e423de1e92716623bf29caac4f06a48283308c33

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @eokoneyo

@eokoneyo eokoneyo merged commit bb54184 into elastic:main Mar 21, 2024
17 checks passed
@eokoneyo eokoneyo deleted the chore/fix-178448 branch March 21, 2024 15:29
@kibanamachine kibanamachine added v8.14.0 backport:skip This commit does not require backporting labels Mar 21, 2024
jloleysens added a commit that referenced this pull request Mar 22, 2024
## Summary

Fix #179058

Update the `transformRequest` function to create URLs that are callable
from inside workers that don't share the same domain.

Proposal is to to convert absolute path values to absolute URLs, e.g.
`/my/path` => `https://my.origin/my/path`.

- [x] Blocked by #178669

## Test locally with CDN

Easiest way to test is via the observability project built on this PR
(see buildkite output), otherwise:

- Build CDN assets (`node ./scripts/build.js --skip-docker-ubi
--skip-docker-ubuntu --skip-docker-fips --skip-os-packages`)
- Unpack the CDN assets
`target/kibana-8.14.0-SNAPSHOT-cdn-assets.tar.gz` and serve them `npx
http-server -p 1772 --cors --gzip --brotli`, remember to change the hash
dir name to `XXXXXXXXXXXX`
- Serve via different domain eg:
```
## My test
127.0.0.1 my.cdn.test
```
- Configure Kibana to load assets `server.cdn.url: http://my.cdn.test`

---------

Co-authored-by: Eyo Okon Eyo <eyo.eyo@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting ci:project-deploy-observability Create an Observability project release_note:skip Skip the PR/issue when compiling release notes Team:SharedUX Team label for AppEx-SharedUX (formerly Global Experience) v8.14.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Serverless-observability-CDN-QA] Monaco editor has unexpected usage error in console
9 participants