-
Notifications
You must be signed in to change notification settings - Fork 30k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update trusted domains based on workspaace remotes
Closes #97532
- Loading branch information
Jackson Kearl
committed
May 12, 2020
1 parent
1636e54
commit 288852d
Showing
3 changed files
with
61 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
288852d
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.
cc @joaomoreno not sure if this would be better in the git extension? 288852d#diff-5251dce8e7eb39c156561693ac352eafR123-R148
We do similar stuff in
vscode/src/vs/workbench/contrib/tags/electron-browser/workspaceTags.ts
Line 105 in 5b33ba2
vscode/src/vs/workbench/contrib/tags/electron-browser/workspaceTagsService.ts
Line 139 in 7bc587d
288852d
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.
@JacksonKearl The git extension already exposes an API, including the remotes of its repos.
288852d
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.
@joaomoreno could you possibly point me to how I can use that?
288852d
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.
Hm... now that I read this better... you can't, since it's an extension API, so you'd have to access it from an extension.
I could give you a hacky
getRemotes
command viavscode/extensions/git/src/api/api1.ts
Line 307 in 94428f8
But not sure... maybe your current approach is good enough. I definitely would not like to add a dependency from the core to the git extension.
288852d
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.
Okay, I can just leave it as-is. thanks!
288852d
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.
Should we really be looking up remotes on every attempt to open a url? Seems quite heavy imo. Also with custom FileSystemProviders, this can be problematic if the fs provider require authentication (which also requires opening a url). I hit this with implementing authentication for the new GitHub serverless fs provider. To deal with it, I've added a short timeout for now, but this needs a better fix: e3de1b8
288852d
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.
We could cache per-workspace/session pretty easily, but that doesn't get around the auth problem.
I think it an approach like your patch could be fine if the results were cached and the timeout were made much smaller?
Though the whole point of this was to make codespaces easier to use, so if we cant access the fs without auth there... that's not a great situation.
288852d
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.
I agree that a smaller timeout would be better, but it would be a strange user experience if sometimes urls would prompt and other times not. Maybe not a big deal if we cached the results (even if we stopped waiting for that instance), then in theory only the first time you could get prompted. Although, the whole trusted domains thing feels strange to me, I'm not sure what security is gained by not opening a url (especially if it is http/https)