OCram85/code-server
Archived
1
0
Fork 0
Code Pull Requests 2 Activity
This repository has been archived on 2024-09-09. You can view files and clone it, but cannot push or open issues or pull requests.
fd42b95164
code-server/patches/webview.diff

77 lines
4.2 KiB
Diff
Raw Normal View History

chore: move to patches (#4997) * Move integration types into code-server This will be easier to maintain than to have it as a patch. * Disable connection token Using a flag means we will not need to patch it out. I think this is new from 1.64? * Add product.json to build process This way we do not have to patch it. * Ship with remote agent package.json Instead of the root one. This contains fewer dependencies. * Let Code handle errors This way we will not have to patch Code to make this work and I think it makes sense to let Code handle the request. If we do want to handle errors we can do it cleanly by patching their error handler to throw instead. * Move manifest override into code-server This way we will not have to patch it. * Move to patches - Switch submodule to track upstream - Add quilt to the process - Add patches The node-* ignore was ignoring one of the diffs so I removed it. This was added when we were curling Node as node-v{version}-darwin-x64 for the macOS build but this no longer happens (we use the Node action to install a specific version now so we just use the system-wide Node). * Use pre-packaged Code
2022-03-22 21:07:14 +01:00
Serve webviews from the same origin
Normally webviews are served from vscode-webview.net but we would rather them be
self-hosted.
When doing this CSP will block resources (for example when viewing images) so
add 'self' to the CSP to fix that.
fix: webviews failing to load the iframe HTML (#5103) Code added in 1.65.0 broke webviews when you are hosting them from the same domain.
2022-04-14 20:02:52 +02:00
Additionally the service worker defaults to handling *all* requests made to the
current host but when self-hosting the webview this will end up including the
webview HTML itself which means these requests will fail since the communication
channel between the webview and the main thread has not been set up yet as the
webview itself is not ready yet (it has no HTML and therefore no script either).
Since this code exists only for the authentication case we can just skip it when
it is served from the current host as authentication is not a problem if the
request is not cross-origin.
To test, open a few types of webviews (images, markdown, extension details, etc).
chore: move to patches (#4997) * Move integration types into code-server This will be easier to maintain than to have it as a patch. * Disable connection token Using a flag means we will not need to patch it out. I think this is new from 1.64? * Add product.json to build process This way we do not have to patch it. * Ship with remote agent package.json Instead of the root one. This contains fewer dependencies. * Let Code handle errors This way we will not have to patch Code to make this work and I think it makes sense to let Code handle the request. If we do want to handle errors we can do it cleanly by patching their error handler to throw instead. * Move manifest override into code-server This way we will not have to patch it. * Move to patches - Switch submodule to track upstream - Add quilt to the process - Add patches The node-* ignore was ignoring one of the diffs so I removed it. This was added when we were curling Node as node-v{version}-darwin-x64 for the macOS build but this no longer happens (we use the Node action to install a specific version now so we just use the system-wide Node). * Use pre-packaged Code
2022-03-22 21:07:14 +01:00
Index: code-server/lib/vscode/src/vs/workbench/services/environment/browser/environmentService.ts
===================================================================
--- code-server.orig/lib/vscode/src/vs/workbench/services/environment/browser/environmentService.ts
+++ code-server/lib/vscode/src/vs/workbench/services/environment/browser/environmentService.ts
chore(Code): upgrade to 1.65 (#5047) * docs(CONTRIBUTING): update Code workflow * chore: update vscode to release/1.65 * chore(quilt): ignore patch backup files * chore: refresh/update patches for 1.65
2022-03-31 01:33:58 +02:00
@@ -176,7 +176,7 @@ export class BrowserWorkbenchEnvironment
chore: move to patches (#4997) * Move integration types into code-server This will be easier to maintain than to have it as a patch. * Disable connection token Using a flag means we will not need to patch it out. I think this is new from 1.64? * Add product.json to build process This way we do not have to patch it. * Ship with remote agent package.json Instead of the root one. This contains fewer dependencies. * Let Code handle errors This way we will not have to patch Code to make this work and I think it makes sense to let Code handle the request. If we do want to handle errors we can do it cleanly by patching their error handler to throw instead. * Move manifest override into code-server This way we will not have to patch it. * Move to patches - Switch submodule to track upstream - Add quilt to the process - Add patches The node-* ignore was ignoring one of the diffs so I removed it. This was added when we were curling Node as node-v{version}-darwin-x64 for the macOS build but this no longer happens (we use the Node action to install a specific version now so we just use the system-wide Node). * Use pre-packaged Code
2022-03-22 21:07:14 +01:00
@memoize
get webviewExternalEndpoint(): string {
- const endpoint = this.options.webviewEndpoint
+ const endpoint = (this.options.webviewEndpoint && new URL(this.options.webviewEndpoint, window.location.toString()).toString())
|| this.productService.webviewContentExternalBaseUrlTemplate
|| 'https://{{uuid}}.vscode-webview.net/{{quality}}/{{commit}}/out/vs/workbench/contrib/webview/browser/pre/';
Index: code-server/lib/vscode/src/vs/server/node/webClientServer.ts
===================================================================
--- code-server.orig/lib/vscode/src/vs/server/node/webClientServer.ts
+++ code-server/lib/vscode/src/vs/server/node/webClientServer.ts
@@ -280,6 +280,7 @@ export class WebClientServer {
const data = (await util.promisify(fs.readFile)(filePath)).toString()
.replace('{{WORKBENCH_WEB_CONFIGURATION}}', escapeAttribute(JSON.stringify({
remoteAuthority,
+ webviewEndpoint: vscodeBase + '/static/out/vs/workbench/contrib/webview/browser/pre',
_wrapWebWorkerExtHostInIframe,
developmentOptions: { enableSmokeTestDriver: this._environmentService.driverHandle === 'web' ? true : undefined },
settingsSyncOptions: !this._environmentService.isBuilt && this._environmentService.args['enable-sync'] ? { enabled: true } : undefined,
chore(Code): upgrade to 1.65 (#5047) * docs(CONTRIBUTING): update Code workflow * chore: update vscode to release/1.65 * chore(quilt): ignore patch backup files * chore: refresh/update patches for 1.65
2022-03-31 01:33:58 +02:00
Index: code-server/lib/vscode/src/vs/workbench/common/webview.ts
chore: move to patches (#4997) * Move integration types into code-server This will be easier to maintain than to have it as a patch. * Disable connection token Using a flag means we will not need to patch it out. I think this is new from 1.64? * Add product.json to build process This way we do not have to patch it. * Ship with remote agent package.json Instead of the root one. This contains fewer dependencies. * Let Code handle errors This way we will not have to patch Code to make this work and I think it makes sense to let Code handle the request. If we do want to handle errors we can do it cleanly by patching their error handler to throw instead. * Move manifest override into code-server This way we will not have to patch it. * Move to patches - Switch submodule to track upstream - Add quilt to the process - Add patches The node-* ignore was ignoring one of the diffs so I removed it. This was added when we were curling Node as node-v{version}-darwin-x64 for the macOS build but this no longer happens (we use the Node action to install a specific version now so we just use the system-wide Node). * Use pre-packaged Code
2022-03-22 21:07:14 +01:00
===================================================================
chore(Code): upgrade to 1.65 (#5047) * docs(CONTRIBUTING): update Code workflow * chore: update vscode to release/1.65 * chore(quilt): ignore patch backup files * chore: refresh/update patches for 1.65
2022-03-31 01:33:58 +02:00
--- code-server.orig/lib/vscode/src/vs/workbench/common/webview.ts
+++ code-server/lib/vscode/src/vs/workbench/common/webview.ts
@@ -24,7 +24,7 @@ export const webviewResourceBaseHost = '
chore: move to patches (#4997) * Move integration types into code-server This will be easier to maintain than to have it as a patch. * Disable connection token Using a flag means we will not need to patch it out. I think this is new from 1.64? * Add product.json to build process This way we do not have to patch it. * Ship with remote agent package.json Instead of the root one. This contains fewer dependencies. * Let Code handle errors This way we will not have to patch Code to make this work and I think it makes sense to let Code handle the request. If we do want to handle errors we can do it cleanly by patching their error handler to throw instead. * Move manifest override into code-server This way we will not have to patch it. * Move to patches - Switch submodule to track upstream - Add quilt to the process - Add patches The node-* ignore was ignoring one of the diffs so I removed it. This was added when we were curling Node as node-v{version}-darwin-x64 for the macOS build but this no longer happens (we use the Node action to install a specific version now so we just use the system-wide Node). * Use pre-packaged Code
2022-03-22 21:07:14 +01:00
export const webviewRootResourceAuthority = `vscode-resource.${webviewResourceBaseHost}`;
-export const webviewGenericCspSource = `https://*.${webviewResourceBaseHost}`;
+export const webviewGenericCspSource = `'self' https://*.${webviewResourceBaseHost}`;
/**
* Construct a uri that can load resources inside a webview
fix: webviews failing to load the iframe HTML (#5103) Code added in 1.65.0 broke webviews when you are hosting them from the same domain.
2022-04-14 20:02:52 +02:00
Index: code-server/lib/vscode/src/vs/workbench/contrib/webview/browser/pre/service-worker.js
===================================================================
--- code-server.orig/lib/vscode/src/vs/workbench/contrib/webview/browser/pre/service-worker.js
+++ code-server/lib/vscode/src/vs/workbench/contrib/webview/browser/pre/service-worker.js
@@ -188,9 +188,11 @@ sw.addEventListener('fetch', (event) =>
}
}
- // If we're making a request against the remote authority, we want to go
- // back through VS Code itself so that we are authenticated properly
- if (requestUrl.host === remoteAuthority) {
+ // If we're making a request against the remote authority, we want to go back
+ // through VS Code itself so that we are authenticated properly. If the
+ // service worker is hosted on the same origin we will have cookies and
+ // authentication will not be an issue.
+ if (requestUrl.origin !== sw.origin && requestUrl.host === remoteAuthority) {
switch (event.request.method) {
case 'GET':
case 'HEAD':
Copy Permalink