Need to allow GitLens to connect to GitHub in every Codespace

[egamma]

GitLens shows the following dialog whenever I open a new Codespace:

Suggest to use the new API context.globalState.setKeysForSync so that my choice is remembered across different Codespaces.

The follow-up problem is when I select "Allow" in the dialog, then I have to do a auth flow in GitHub, but I'm already logged into GitHub.

[corwin-of-amber]

If I just want the plain git history functionality, and click "Deny Everywhere", then I still have a nagging notification in the accounts icon on the bottom left. 😢

[eamodio]

@egamma So there is a bunch of back-story to why that notification exists. But the TLDR version is I'm blocked by microsoft/vscode#111529

Today the VS Code authentication api provide a authentication.getSession(<id>, <scopes>, { createIfNone: false }) that allows an extension to get an existing session if one exists. This works great for the case when there is no matching (scopes) authentication session -- e.g. it is silent. BUT if there is a matching authentication session, AND the extension hasn't be granted access to it -- then VS Code pops up a dialog like this:

This creates a big issue for extensions, because we have no way to silently know if we have an authorized session or not. So because GitLens tries to figure out if it has an authorized session to provide passive features (i.e. features that the user doesn't take an explicit action to invoke), and because that prompt is not at all friendly to the user if they didn't do anything to cause it, I added an explanatory notification to tell the user what will happen and why, and offer a way to completely opt-out.

So until microsoft/vscode#111529 is fixed/addressed I don't think there is really much I can do. You can disable the integration completely, by setting "gitlens.integrations.enabled": false in your settings. And I am currently syncing the Deny Everywhere choice, but I was/am very hesitant to sync the Allow choice to other machines, because I might want to allow it on my home machine, but not on my work machine, etc. Although I guess I could add an Allow Everywhere button if you want to opt-into that.

Also as for:

The follow-up problem is when I select "Allow" in the dialog, then I have to do a auth flow in GitHub, but I'm already logged into GitHub.

That is also completely controlled by VS Code

And @corwin-of-amber your issue is also out of my hands and is fully controlled by VS Code.

[egamma]

@eamodio thanks for the background!

[jrieken]

This creates a big issue for extensions, because we have no way to silently know if we have an authorized session or not

@eamodio Are you saying that you want silent access to a session or silent knowing that a session would exist if you would be asking for it?

prompt is not at all friendly to the user if they didn't do anything to cause it, I added an explanatory notification to tell the user what will happen and why

Instead of silent access and custom notifications wouldn't it be better to provide a reason for why you want to get a session? That would allow to make a UI more friendly/informative and wouldn't rely on notifications popping up. With GH issue notebooks I have the same challenge: it works well except for thinks like author: @me or quota restriction. I would also like to explain that to users, but not with custom UX

[eamodio]

@jrieken

Are you saying that you want silent access to a session or silent knowing that a session would exist if you would be asking for it?

To me that are kind of one and the same. I want/need to be able to get access to a session that I've been previously granted access without prompting the user if there isn't one.

Instead of silent access and custom notifications wouldn't it be better to provide a reason for why you want to get a session?

Having a reason (and possibly a more global opt-out) on our prompts would be very nice, but I don't think that helps address my silent access concern. In GitLens, I want to use the access if I have been granted it, passively (for avatar lookups, pr & issue linking details, etc) but I don't want to prompt/bother the user UNLESS they take a specific action (or actions) to opt-in to wanting to connect to GitHub to provide those features.

/cc @RMacfarlane

[jrieken]

I want/need to be able to get access to a session that I've been previously granted

"I" as the user or the extension?

[eamodio]

Extension