-
Notifications
You must be signed in to change notification settings - Fork 889
feat(cli): add coder open vscode
#11191
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
Conversation
b4abb31
to
36c7e20
Compare
Do we need to specify workspace name everytime? |
Yes I agree it should be replaced with "Opening vscode desktop in workspace w" |
This version was intended only for opening from a users local machine. Opening from within the workspace on the local machine is much more complicated, although I agree would be convenient. Opening from the workplace is a much harder problem since we can’t tell the users machine to execute a command from within the SSH session. The best we can do for now within the workspace is to print the open uri and let the user open it themselves. Or, we can print a URL to the dashboard (solves the issue of providing the token without printing it in the terminal). If getting the same automatic open experience remotely as locally is a hard requirement. Then I’d like to discuss with @deansheather about security implications and whether or not we should do it.
I did consider it, but I’m worried we’ll overload the top level scope with too many commands if we do that. Especially if more open commands are introduced. |
I agree with naming. For allowing opening from the web terminal, it's just convenient and saves user from having to install coder locally first before using this command. |
VSCode itself doesn't support "local open" in an SSH session outside of the integrated terminal so I don't think we should either. You can't SSH into a server and then run There are security issues with adding a reverse shell or support for the workspace to open URLs on the local machine without input as well. A malicious workspace could run custom commands or could abuse custom scheme handlers to coerce other apps on the local system to do malicious actions. Or it could just DoS your local machine by spamming URLs. |
0384ac8
to
42c6b03
Compare
This comment was marked as outdated.
This comment was marked as outdated.
49025a5
to
5d370fc
Compare
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.
Great Work. I am happy withe functionality and will defer code review to engineers.
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.
LGTM 👍 I think we could probably extract some util / helper functions from the command though, especially around the windows path handling logic.
// Path starts with a drive letter. | ||
return len(path) == 2 || (len(path) >= 4 && path[2] == '\\' && path[3] == '\\') | ||
default: | ||
return false |
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 tried /path/to/something
, \path\to\something
and C:/path/to/something
which also both work in VSCode. Defaults to the drive Windows is installed on if there isn't a drive letter.
IDK how paths work in Windows containers either, unsure if they have drive letters or not.
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.
Maybe I'll need to play around with this some more. I was actually planning on testing with agents on Windows today, but it turns out our win template is broken atm. I know at least the "expanded directory" resolves to C:\...
via test runners. I suspected /
might work in VS Code but out of precaution I wanted to transform them.
Perhaps we can just make everything slash and only have the logic for detecting abs path on Windows.
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 added some handling for the cases you mentioned, and relaxed the abs requirement to include /
, \
. I know there are more exceptions like \\.UNC\
paths and the like, but I don't know if it's worth adding preemptive handling for that.
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.
Actually, I can't seem to make CI happy because Go filepath.IsAbs
on windows seems to think differently? https://github.com/coder/coder/actions/runs/7262677715/job/19786347550?pr=11191#step:5:496
(I kept the fallback to filepath
vs our impl. on Windows so that we could catch these types of inconsistencies, but I can just remove that if we don't care.)
7b54988
to
cdea111
Compare
3c3564a
to
b1f10a7
Compare
df26e52
to
2e9f563
Compare
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 think it's probably fine if we don't cover every single edge case on Windows, especially since not many of our customers are using Windows workspaces. If we do find issues they can be fixed later
7f04d9d
to
d09546c
Compare
This PR adds support for
coder open vscode
that can be used on a local machine or remote.On a local machine, the URI is automatically opened via platform specific open methods (open, xdg-open, etc.) and on a remote machine the URI is printed to the console (or if automatic open fails).
As a (maybe overkill?) security precaution, we don't print the API key by default, it has to be requested with
--generate-token
. The automatic open code-path always includes it, though. Just like the Web UI.The most unfortunate part of this PR is the path handling (due to Windows). It could be simplified at the loss of convenience, or it could be refactor to be more robust, the latter I don't feel is in scope for this PR, though.
In a future incantation, we may even go as far as SSH into the workspace to expand the path which would resolve a lot of issues -- maybe even allow tab-autocompletion once that's are re-introduced.
Alternatively, in another future improvement, it would be nice if the agent reported the
$HOME
, this way we'd have a fallback for whenExpandedDirectory
is empty.Fixes #7667