code-server: [Bug]: GitHub login status gets lost after restarting of code-server daemon
Is there an existing issue for this?
- I have searched the existing issues
OS/Web Information
- Web Browser: FireFox
- Local OS: Fedora 36 Workstation Beta And Windows 11
- Remote OS: Fedora Server 36 Beta
- Remote Architecture: x86_64
code-server --version:4.2.0 693b1fac04524bb0e0cfbb93afc85702263329bb with Code 1.64.2
Steps to Reproduce
- Install GitHub related addons, e.g. copilot
- Login the extension
- Restart code-server via
systemctl restart code-server@user - Reopen code page
Expected
GitHub login status should persist, no need to re-login
Actual
extension asked to login again
Logs
No response
Screenshot/Video
No response
Does this issue happen in VS Code?
- I cannot reproduce this in VS Code.
Are you accessing code-server over HTTPS?
- I am using HTTPS.
Notes
The disscussion may provide more infomation. https://github.com/coder/code-server/discussions/5052
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 8
- Comments: 30 (12 by maintainers)
I created this to solve the problem. Since vscode expects keytar I just implemented it in NodeJS and had it write to a file. It does not perform the same keyring activity that the original does - it’s more or less a simple keystore.
https://github.com/stevenlafl/node-keytar/blob/master/lib/keytar.js
You can encrypt it with environment variable ENCRYPTION_KEY, though it’s visible to VSCode, so I am not sure how useful that feature is to anyone yet.
So, in a Dockerfile:
Then volume mount
/home/coder/.local/credsto wherever you want. (of course,chownit from within the container socodercan access it)I have the same issue. Previously (up to code-server v4.1.0) the credentials were stored in the browser storage (maybe indexed DB or local storage - haven’t checked it in detail).
Since code-server v4.2.0 the credentials are not stored in the browser anymore, but apparently they are stored in-memory on the server. Thus restarting the server causes it to forget them (as described above).
The following log might be related to this, since it mentions switching to an in-memory credential store because
keytarfailed to load. On the other hand, it looks likekeytaris intentionally not installed: https://github.com/coder/code-server/issues/5018 and we wouldn’t want to use keytar, because then the credentials would be stored in the hosts local keyring / keychain.Yeah for a long time I didn’t have this problem, on the newer versions I do again (4.16.1)
In fact, its even worse in the sense that every time I reload I have to re-login
The same issue on v4.16.1.
I have this same isuue.
@rohit901 I never claimed that this method works with GitHub Copilot[^1].
ℹ️ This extension may only be used with VS Code from Microsoft.
[^1]: I do not know, if a personal access token with scopes
repoanduseris sufficient for GitHub Copilot – it is for GitHub Pull Requests and Issues, though.My advice: Keep your hands off GitHub Copilot.
https://drewdevault.com/2022/06/23/Copilot-GPL-washing.html
GH login session will still expire if the code-server daemon is restarted on v4.13.0
I restart my server every morning to free the memory etc…So I have to log in to copilot and GH repo every day…I hope we can solve this issue and it would save much of time.
Appreciate it!
@benz0li copilot is still asking to sign in using github, each time i quit server and open again. I generated my personal access token with the repo and user scope as you said, putting it in GITHUB_TOKEN environment variable and starting code-server with:
.local/bin/code-server --bind-addr 0.0.0.0:11000P.S.: The same applies for the GitLab Workflow extensions, i.e. set environment variables
GITLAB_WORKFLOW_INSTANCE_URLandGITLAB_WORKFLOW_TOKENbefore starting code-server.Thanks, it seems to be working now.
I need to know when this problem is going to be fixed?
I think a proposal to change secret storage would make more sense upstream rather than a patch here in code-server but there might be an existing method that works better because Codespaces does not seem to spawn dbus yet presumably secrets work there. So if we can figure that out maybe we can leverage it in code-server.
Huh yeah my memory is also that it used to be in browser storage so if they moved it out that would explain the problem.
Our Linux builds were silently not including keytar (yarn failed to build but never errored) because we were missing the libsecret dependency which I think we added recently so hopefully that means it stops using the in-memory store (from 4.9.1 onward I think).