Live-share: Unable to sign into Live Share from VS Code - no browser appears

[letmaik]

Product and Version [VS/VSCode]: VSCode Insiders 1.20.0
OS Version [macOS/Windows]: Windows
Live Share Extension Version: 0.2.66

I started a session and sent the link to the guest who then clicked on it after which a new VS Code opened. Then nothing happened. Note that the guest was not logged in. No further browser window popped up asking the guest to sign in.

Logs of guest: logs.zip

[jasongin]

The logs indicate that the guest VS Code is stuck waiting for the user to sign in. It should have launched a browser window to the Live Share sign-in page. Either launching the browser failed (and the extension didn't detect that failure), or the browser was launched but maybe the user didn't notice because it was in a non-focused window.

[jasongin]

To be clear, I'm not saying this is definitely a user error... It's possible there's a bug here. I'm just relaying my initial interpretation of the logs.

[Chuxel]

@letmaik Out of curiosity, did you happen to notice if the lower left hand corner status bar was saying "Signing in..." or anything like that when this happened? The question is whether the browser pop-up didn't fire for some reason as Jason mentioned.

Regardless, two other questions:

1. If the person who joins signs in first and then clicks on the link does it work?
2. If you try manually joining, does the join work? http://aka.ms/vsls-docs/manual-join

[Chuxel]

As a workaround for those that are hitting a problem with the browser not appearing even when trying to sign in, follow these steps:

1. Go to https://insiders.liveshare.vsengsaas.visualstudio.com/auth/login and sign in.
2. After signing in in the browser, click "Having trouble?"
3. Follow the directions to enter a user code into the tool.

[letmaik]

I just tried it again and can confirm that no browser window popped up and it also doesn't say "Signing in...".
I cannot test whether it works when manually signing in as the guest doesn't want to continue with the signing process since Live Share is asking GitHub for his personal email address which he thinks is not necessary to disclose to Microsoft. I think that is a reasonable concern since the only need for an email address would be to send (advertisement or announcement) emails. As far as I see it, the whole point of signing in is so that the host can see who the person is, and for that the GitHub identity (user name) is enough. The email address wouldn't be shared with the host anyway.

[Chuxel]

@letmaik That's interesting feedback!

Signing in does not add him to any marketing emails in any way. Even signing up for the preview is limited to us sending information and invites specifically for Live Share to simply keep you updated on how we are progressing given interest.

The reason the sign in is present in the product is to assure that the individuals that have joined your session are who they say they are. It's actually a security feature. We've also considered allowing you to limit invite links based on email or an ID for these reasons. (#80, #4, #13, #14)

That said, we do have a feature request for full anonymous access (#3) that might be worth up-voting. It is something we've wondered about for certain circumstances. I'd be interested to hear if this would eliminate the guest's concerns.

[letmaik]

@Chuxel Thanks for explaining the motivation behind it. The guest would have no concern if there was an anonymous joining option. I think especially outside corporate environment this has a lot of value and removes barriers.
Having said that, let's get back to the email address again. The guest would also be happy if the email address wasn't shared with Live Share when logging in via GitHub. It's all about reducing your digital footprint basically. But even if you argue against it, I think it doesn't make sense to use the GitHub email address for the purpose you're describing (limiting access), since normally that email address is not known, compared to the user name. And it also wouldn't make much sense in a corporate environment since developers often keep using their existing GitHub account when joining a company, and the email address then does not necessarily equal the corporate one.
I think limiting the access in the non-corporate users scenario only makes sense based on GitHub user names and Microsoft account email addresses. And for corporate cases, GitHub organization/team membership could be used instead.

[lostintangent]

@letmaik You make a great point! For the sake of host-awareness, it’s potentially only important that folks can see the verified identity of any guests who are joining a collaboration session, which in the case of GitHub, could simply be based on public information (username, avatar, name?). Beyond discussing anonymous access, it seems worth considering allowing guests to sign in without providing access to the _any_ private information, which could include email addresses.

Additionally, since a GitHub username is already the natural way of identifying people (e.g. mentioning someone on a PR), and a GitHub identity can be associated with many e-mail addresses, it makes sense to consider allowing it as the way to invite GitHub guests, as opposed to emails, once we move forward with that feature enhancement. Thanks so much for this feedback!

[Chuxel]

@letmaik @lostintangent Got it. Makes sense. Yeah certainly we could drop back to just GitHub username from a scope perspective once we are out of private preview. Right now sadly it matches on email to see who accepted in the preview in since that is all we have from the signup.

We should probably update the feature request on locking down on email to be GitHub or email as well since the key is just some source of identity you can count on. Appreciate the insight!

[Chuxel]

@jasongin I just repo'd this locally. I was joining @lostintangent's VS Code session via the browser. The sign in prompt and/or browser did not pop up and it just said "sign in" down below.

However, after clicking "Sign in", the browser popped, I signed in, and the join automatically started and worked. Seems like some sort of race condition maybe?

Logs attached.
clantz-failed-signin.zip

[Chuxel]

Merging in #128 from @i-love-code

---

Product and Version [VS/VSCode]: VSCode
OS Version [macOS/Windows]: Windows
Target Platform or Language [e.g. Node.js]: Nodejs, if that's relevant

Steps to Reproduce / Scenario:

1. Send invite link to user with VS Code who is not signed into a personalization account. This user was also a guest (not part of VSLive beta)
2. The guest clicking the invitation link will see VSCode open to the VSCode start page
3. There is no prompt to sign into a personalization account to start collaboration, causing some general confusion on what the guest is supposed to be looking for
4. Signing into a personalization account starts the collaboration experience as expected after clicking the invitation link again

[Chuxel]

The repro on this appears to be related to a Live Share update or first install. If a guest installs the extension but does not reload and wait for the install step (as seen in the status bar) to complete they will not be prompted to sign in and therefore join the collaboration session after this is done. If they join the collaboration session after this has completed things will work as expected. This was potentially introduced when #58 was resolved but it may have existed before this as well.

The workaround is simply to click on the link (or just the "join" command) after the install has completed, but this shouldn't be happening.

[Chuxel]

We just released v0.2.399 that should resolve this issue! Let us know if it is still happening for you.

[akulagrawal]

Hi, I recently encountered the same issue with vs live share sign in. Neither the browser option is working, not the user code one. Logs attached
logs.zip

[anderflash]

Same here, Archlinux + (Palemoon or Firefox) + VS Code 1.43.1-1 + Live Share 1.0.1847.
"Signing in..." still visible. Is it something related to OAuth2 authentication?
There is a "code-oss://ms-vsliveshare.vsliveshare/signin?..." on the browser with the error "The address wasn’t understood" (Firefox). So, is it supposed to be redirected from the Browser to VS Code?

[joao-rafael]

Also, same issue on Ubuntu 20.04 with VsCode, Signing in is visible but it appears to be an infinity loop.

[oleks12345]

I fixed it by downloading codium, starting live share, it said that I'm missing dependencies, it prompted terminal, with script to download it :) after downloading, it work in vs code

[daytonellwanger]

Hi all, first off, sorry for the slow response time!

Second, it'd be very helpful if you could attach your logs to this issue (from the command palette - ctrl + shift + p "Live Share: Export Logs") so we can see where things are getting hung up. Thanks in advance!

[barisere]

I have the same problem. I am running VS Code on openSUSE Tumbleweed. The browser window pops up and I grant access in the OAuth flow. The OAuth redirect opens a link in VS Code, but the sign in does not complete.
Here are the exported logs: live_share_logs.zip

[H8to]

with script to download it :) after downloading, it work in vs code

Does not work for me, as Microsoft and Github block the redirection URLs.

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

Could you specify the dependencies that were missing @oleks12345 in order to manually fix this issue or share the script please?

Edit: In my case it was Pihole (DNS-Blacklist) blocking the Telemetry URL:
  | vortex.data.microsoft.com
Not fully sure, but now it works. Please investigate if blocked telemetry does result in a fail.

[2020-06-17 10:16:40.166 Command:Object I] Decorator: SessionStateTransitions Completed Failed (20ms abs=2ms pre=1ms post=1)
[2020-06-17 10:16:40.166 Contact.Manager V] suggest contacts from provider:selfInvite ids: emails:
[2020-06-17 10:16:40.166 Command:Object I] Decorator: Validation Completed Failed (20ms abs=0ms pre=0ms post=0)
[2020-06-17 10:16:40.166 Contact.Manager V] ->updateRecentContacts -> count:0
[2020-06-17 10:16:40.166 Contact.Manager I] <- updateSuggestedUsers count:0
[2020-06-17 10:16:40.166 Command:Object I] Decorator: TelemetryStatus Completed Failed (20ms abs=0ms pre=0ms post=0)
[2020-06-17 10:16:40.657 Command:Object E] Command [Signing in]: ExplicitSignIn Cancelled:  (511ms)
[2020-06-17 10:16:40.657 Command:Object E] Error: 
    at AuthenticationCommandDecorator.invoke [PATH]/extension-prod.js:19114:31)
    at processTicksAndRejections [PATH]/task_queues.js:85:5)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async SessionStateTransitionsCommandDecorator.invoke [PATH]/extension-prod.js:19560:22)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async ValidationCommandDecorator.invoke [PATH]/extension-prod.js:19922:18)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async TelemetryStatusCommandDecorator.invoke [PATH]/extension-prod.js:19869:22)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async TelemetryCommandDecorator.invoke [PATH]/extension-prod.js:19728:22)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async ErrorNotificationCommandDecorator.invoke [PATH]/extension-prod.js:19312:22)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async CancellationDecorator.invoke [PATH]/extension-prod.js:19238:18)
    at async MetaProfilingCommandDecorator.invoke [PATH]/extension-prod.js:19398:22)
    at async [PATH]/extension-prod.js:7511:24
[2020-06-17 10:16:40.657 Command:Object I] Decorator: Telemetry Completed Failed (512ms abs=492ms pre=1ms post=491)
[2020-06-17 10:16:40.657 Command:Object I] Decorator: ErrorNotification Completed Success (512ms abs=0ms pre=0ms post=0)