Skip to content
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

Blocking External Users #2018

Closed
RDavies2019 opened this issue Apr 24, 2019 · 7 comments
Closed

Blocking External Users #2018

RDavies2019 opened this issue Apr 24, 2019 · 7 comments
Assignees

Comments

@RDavies2019
Copy link

This is neither bug nor a feature request, so I don't know where to put it. It's more of a "how to" question.

Is there a way to block users outside our company from joining a session? For example, maybe I only want to accept accounts that fall under our domain, user@ourdomain.com. I did find a setting to reject guests, so that's a start.

I'm in IT. A developer requested Live Share, and I'm trying to evaluate it from a security standpoint. Thank you for your help.

@lostintangent
Copy link
Member

@RDavies2019 We don’t currently have a mechanism for this, though its on our roadmap. Currently, we have support for two things:

  1. You can require guests be explicitly approved into the session, which would allow the host developer to be confident that no one unexpectedly joined

  2. You can specify that you’ll only allow direct connections from guests, which would have the effect of rejecting any join requests from people that weren’t on the same subnet. That said, this would also prevents people within your organization from collaborating, if they weren’t on the exact same subnet

If you’d like, I’d be happy to chat further about this. Feel free to ping me at joncart@microsoft.com.

@RDavies2019
Copy link
Author

Ok, great. You saved me time looking for something that doesn't exist.

Is there a way to lock down the settings (found under File-->Preferences-->Settings-->Extensions-->Visual Studio Live Share), so that they can be altered only by an admin?

@lostintangent
Copy link
Member

Unfortunately not. Centrally-managed settings is also on our roadmap, but there isn’t currently a solution for that.

@RDavies2019
Copy link
Author

You've been so helpful, so I hope you won't mind two more questions.

  1. Is there any way to force participants to follow the host, so that participants can only ever see what file the host is focused on? Any collaborative or screen-sharing tool has some risk, but at least with a screen share, one person at a time controls the session, and the host and guest always see the same things. With this tool, merely by clicking elsewhere I could lose track of what my participants are doing.

  2. Suppose I share a read/write terminal. Is the command history (and who executed commands) stored anywhere? In general, is participant activity stored anywhere?

@lostintangent
Copy link
Member

lostintangent commented Apr 25, 2019

Neither of those currently have a solution either. The ability for participants to independently navigate is actually one of our core value props, though for certain use cases (e.g. classroom lectures), we’ve heard interest in forcing guests to follow. We’re currently tracking this via #87. If you could upvote that issue, and add any extra requirements info, that would be awesome!

Additionally, we don’t currently track terminal activity anywhere. Though we’ll be working on a general “activity log” soon, that will include terminal actions, along with edits, etc.

@jtbandes
Copy link

Hi @lostintangent, just wondering if there have been any updates on this roadmap since last year when this issue was opened?

@lostintangent
Copy link
Member

Closing this as a duplicate of #2.

@jtbandes We recently released a simple extension called Live Share Gatekeeper that will automatically block guests outside of the domain of the host. Let me know if that suits your needs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants