Skip to content

feat: allow magic string to generate session token for external apps #9878

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

Merged
merged 3 commits into from
Sep 26, 2023

Conversation

kylecarbs
Copy link
Member

@kylecarbs kylecarbs commented Sep 26, 2023

This will enable modules to replace built-in apps like VS Code Desktop by having long-lived user-scoped tokens dynamically.

@kylecarbs kylecarbs self-assigned this Sep 26, 2023
@kylecarbs kylecarbs enabled auto-merge (squash) September 26, 2023 18:25
Copy link

@cdr-bot cdr-bot bot left a comment

Choose a reason for hiding this comment

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

This PR is a hotfix and has been automatically approved.

  • ✅ Base is main
  • ✅ Has hotfix label
  • ✅ Head is from coder/coder
  • ✅ Less than 100 lines

Copy link
Member

@aslilac aslilac left a comment

Choose a reason for hiding this comment

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

one minor thing I wanna double check: do we require that app urls be a full, well formed url, or can it be a relative path?

if (app.external && !app.url.startsWith("http")) {
// If the protocol is external the browser does not
// redirect the user from the page.
window.location.href = href
Copy link
Member

Choose a reason for hiding this comment

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

I'd say we should just not prevent default and let the browser do it's thing

Copy link
Member

Choose a reason for hiding this comment

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

also I feel like this should be an || not a && right? if it was labeled as external by the template, or it's not an http/https link, then we cannot open it as a new window

Copy link
Member

Choose a reason for hiding this comment

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

The browser does the redirect but leaves an empty window artifact.

Copy link
Member Author

Choose a reason for hiding this comment

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

An app can be external and not HTTP(s), in which case we'd want to open it in a new window I believe.

Copy link
Member

Choose a reason for hiding this comment

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

Yes that's the current behavior. We are just adding an exception for non http ones.
Having a window or tab is another debate. But let's leave that for now.

Copy link
Member

Choose a reason for hiding this comment

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

The browser does the redirect but leaves an empty window artifact.

oh because of the _blank, right? we could make that value depend on app.external to fix that.

Copy link
Member

Choose a reason for hiding this comment

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

An app can be external and not HTTP(s), in which case we'd want to open it in a new window I believe.

but the new window will still be a browser, only capable of opening http and https links. I'd expect that anything that's not http should not be opened in a new window

Copy link
Member Author

Choose a reason for hiding this comment

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

I think if it's not labeled as external then we'd technically want to proxy it through the workspace, which I agree is weird, but don't wanna have a shot at breaking anyone right now before launch.

@kylecarbs kylecarbs requested a review from aslilac September 26, 2023 18:44
@kylecarbs kylecarbs changed the title fix: make non-http external app links open in the current window feat: allow magic string to generate session token for external apps Sep 26, 2023
Comment on lines 120 to 132
getApiKey()
.then((key) => {
const url = href.replaceAll(
magicTokenString,
key.key,
);
window.location.href = url;
setFetchingSessionToken(false);
})
.catch((ex) => {
console.error(ex);
setFetchingSessionToken(false);
});
Copy link
Member

Choose a reason for hiding this comment

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

you could just make this event handler async and then await these

Copy link
Member Author

Choose a reason for hiding this comment

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

I suppose that's the same as console.error really, will change

);
// This is an external URI like "vscode://", so
// it needs to be opened with the browser protocol handler.
if (app.external && !app.url.startsWith("http")) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm still pretty convinced this should be an ||

Copy link
Member Author

Choose a reason for hiding this comment

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

If app.external and the URL is https://my-internal-jira.com we wouldn't want to replace window.location.href, otherwise it would redirect the user from the dashboard.

Copy link
Member Author

Choose a reason for hiding this comment

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

@aslilac lmk async if I'm thinking of this wrong, going to merge since it's blocking some registry work, but I'm happy to change it!

Copy link
Member

Choose a reason for hiding this comment

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

OH. I think I misunderstood what external meant here. It's probably fine.

@kylecarbs kylecarbs merged commit 726a4da into main Sep 26, 2023
@kylecarbs kylecarbs deleted the applink branch September 26, 2023 21:04
@github-actions github-actions bot locked and limited conversation to collaborators Sep 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants