-
Notifications
You must be signed in to change notification settings - Fork 23
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
Support extension UriHandler
s
#19
Comments
@TylerLeonhardt I'm new to the callback, and don't know how the flow works. I (blindly) adopted what @bpasero did in microsoft/vscode#140329. Can you test it out? (Maybe add some steps so I get an idea how to test it myself) It's just in source, not yet published -> use If I understand this right, ideally this could go to |
There is still a little server dependency to serve |
In the meantime we've adopted the new fully serverless @TylerLeonhardt Is the more needed to get the auth flow running in Currently, when I try the github authentication flow, I end up with the |
@aeschli GitHub auth doesn't work with localhost. You will have to try either Microsoft auth or I made a test extension for UriHandlers: once you have it running locally, run the command: |
In a vscode extension you can register a URI handler:
https://code.visualstudio.com/api/references/vscode-api#UriHandler
This
UriHandler
will get invoked when an external webpage redirects into VS Code with the extension identifier specified.This works in vscode.dev (thanks to @joaomoreno) where the server sets up a well-known route (
vscode.dev/callback
) that handles requests that will turn around and invoke registeredUriHandler
s. Note, this works in tandem withvscode.env.openExternal
which will give you the exactUri
to redirect into.vscode-test-web
should have a similar capability and I feel like a lot of the logic can be shared.Additionally, the Microsoft and GitHub auth extensions use
UriHandler
for logging in so this means that extensions that use our in-box auth extensions can not be tested invscode-test-web
either.Workaround
Sideloading the extension on vscode.dev works around this and still allows the author to test their extension on web.
The text was updated successfully, but these errors were encountered: