microsoft / vscode-remote-repositories-github

Quickly browse, search, edit, and commit to any GitHub or Azure Repos repository directly from within Visual Studio Code.
Creative Commons Attribution 4.0 International
198 stars 94 forks source link

Support Virtual Workspaces without sign in with GitHub #74

Open alefragnani opened 3 years ago

alefragnani commented 3 years ago

The Virtual Workspaces features is a really neat solution for browsing and quick editing remote repositories, but even being understandable to support only GitHub repos out of the box, I don't see why it forces the user to sign in with GitHub in order to load any repository.

Sure, you must be sign in to properly edit/save/commit changes on repos that you are authorized to do so, but because the feature is not limited only to repos that I'm allowed to push, I could, in theory, browse the contents of any public/available repo, even without signing in.

Thank you

eamodio commented 3 years ago

@alefragnani Thanks for the suggestion! We do have this tentatively planned for the June release.

0cjs commented 2 years ago

FWIW, this is putting off at least a few potential users. Someone mentioned web-based VSCode to me, so I loaded it up and the first thing I did was click the very attractive "Open Remote Repository" button and type the URL of a public repo. My next action, after being asked for entirely unnecessary access to private and sensitive information on a computer that I didn't even trust with my GitHub login credentials, was to click the "close" button on that tab and move on to other things.

I'm subscribed to this ticket, now, so I'll be able to come back to it when I can do a simple demo without having to give away access to sensitive information.

joyceerhl commented 2 years ago

Capturing some of the discussions we've had around this--the main challenge here is GitHub's API rate limits, which are quite aggressive if you are not authenticated (capped at 60 requests per hour). github1s also has the same issue, and they recommend signing in if you happen to hit the limit https://github.com/conwnet/github1s/blob/master/docs/guide.md#rate-limit We would want to deal with this in a graceful manner, which means keeping track of the number of requests we have already made and notifying the user that they need to sign in because they've maxed out the API limit. Given that we want to support both authenticated and unauthenticated flows, and we are currently using the v4 GraphQL API in many places (which always requires authentication), we would have to maintain two codepaths for viewing repos.

TLDR this is doable but we're waiting on additional user feedback for this use case and also thinking about how to add support for this scenario in a maintainable way.

omar2205 commented 2 years ago

It's a lot easier to browse the code in vscode.dev than to open each file or git clone it.

joyceerhl commented 2 years ago

@omar2205 glad to hear that this is helpful--out of curiosity, are you not willing or able to sign in with GitHub to view public repos in vscode.dev? Would like to understand how blocking this is for your vscode.dev workflow. Thanks for the feedback!

omar2205 commented 2 years ago

Sometimes I browse using incognito mode, others not on my main system where I'm logged in. And tbh, it's just too much work to log in just to browse a couple of files.

joyceerhl commented 2 years ago

Was discussing anycode's use case for reading loose GitHub files to build an index for language features in the browser with @jrieken, and he pointed out that even when authenticated to GitHub, it's possible to hit the rate limit just by reading too many files with tar downloads disabled. The GitHub issues notebook extension also runs into this just by running all cells in the endgame notebook a few times when authenticated. So the problem of tracking API requests and handling getting close to the rate limit is not limited to the unauthenticated access scenario. This doesn't mean we will do something here immediately, but it's an additional motivator.

0cjs commented 2 years ago

...the main challenge here is GitHub's API rate limits...

Only if you use the GitHub API. git clone has no issues with rate limits, and presumably neither do you when you're using http: or https: URLs to Git repos on other sites that are simply serving the Git repo in the usual (static) way.

Or is this not an interface to Git repos served over HTTP, but only an interface to GitHub, where you happen to use GitHub's generic Git repo URL to identify the repo, but don't actually use the interface that that implies? If so, you should change the interface to be clear about that.

joyceerhl commented 2 years ago

@0cjs This extension provides the ability to work with a GitHub repository without cloning it locally, as described in this repository's readme.

0cjs commented 2 years ago

There's nothing in the UI indicating that "Open remote URL" is not actually a generic "open remote URL" function and one must go look at the README to see what it does. And it's starting to look more and more as if it's a) not using the URL, but actually just extracting information from the URL and using it elsewhere, and b) doesn't work with anything but GitHub. I tried https://gitlab.com/retroabandon/cbm.git in the box and I get no response to pressing Enter; it just sits there as if I'd not hit Enter.

Just naming the thing "Open GitHub project" would be a really good start. But even better would actually to make it just work as effectively and broadly as git clone. (I guess that assumes you have local file storage somewhere.)