Allow user setttings to persist on server (and/or browser local storage)

Continued from #3061 (comment)

This involves whether to remove the patch where user settings are persisted on the server

Use case

Our developers store their individualized user settings on the server, and this gives the same settings even on new machines
Then, there are "company" defaults stored in Machine.json, e.g. debugger ports, allocated by the "company" and these can vary between developers and not supposed to be modified in any way (I have a script that overwrites them regularly)
I use workspace to store project settings, they contain minimal settings, mainly folder paths settings
So, what is broken now for me is 1, where developers have to "memorize" their changes, and redo them when faced with a new machine

Proposed behavior A

Load settings from browser
- can be individualized, use case: developer personal preferences, can't sync across machines
Overwrite with user settings on server
- can be individualized, use case: developer personal preferences, sync across machines
Overwrite with machine settings on server
- can be individualized, use case: developer devops settings
Overwrite with workspace settings on server
- can't be individualized as it is commited to git
Overwrite with folder settings on server
- can't be individualized as it is commited to git

In response to the comments after #3061 (comment)

Why do we need code-server if it is going to work the same as vscode.dev/Codespaces?
- Because code-server upgrades the VSCode from microsoft, e.g. providing a login screen etc
A laptop/browser is also not the best place to be storing data, it is not ideal for business continuity (backup/device loss etc)
I have been telling colleagues/friends about how I can lose my laptop and still continue from where I was in minutes
vscode.dev have to persist to browser because the user does not have to login, otherwise their servers would have to store unattributable data indefinitely
That said, I know we can still persist to the server, but it is now all lumped together user + machine, which breaks permission controls etc
I think proposal A works as a way forward, alternatively, I can think of proposal B, an idea stemming from the login screen
Proposal B: we can add an entry in config.yaml to define where user settings should persist: local/server

What do you guys think?

@spkane

@spkane Regarding

/home/user/.local/share/code-server/User which contains various settings, including things like:
{
  "security.workspace.trust.enabled": false
}
which I am pretty confident are not allowed to be set by any settings layer besides the User one.

Correct. The 'Workspace Trust' feature can only be disabled in 'User Settings' – the same applies to telemetry settings.
👉 Instead, use option --disable-workspace-trust when starting code-server.

What are the reasons for disabling such a security feature by default? (Should the 'local storage' patch be removed, I might do so as well; I run code-server isolated in a container).

code-server --help

Usage: code-server [options] [path]
    - Opening a directory: code-server ./path/to/your/project
    - Opening a saved workspace: code-server ./path/to/your/project.code-workspace

Options
      --auth                             The type of authentication to use. [password, none]
      --password                         The password for password authentication (can only be passed in via $PASSWORD or the config file).
      --hashed-password                  The password hashed with argon2 for password authentication (can only be passed in via $HASHED_PASSWORD or the config file).
                                         Takes precedence over 'password'.
      --cert                             Path to certificate. A self signed certificate is generated if none is provided.
      --cert-host                        Hostname to use when generating a self signed certificate.
      --cert-key                         Path to certificate key when using non-generated cert.
      --disable-telemetry                Disable telemetry.
      --disable-update-check             Disable update check. Without this flag, code-server checks every 6 hours against the latest github release and
                                         then notifies you once every week that a new release is available.
      --disable-file-downloads           Disable file downloads from Code. This can also be set with CS_DISABLE_FILE_DOWNLOADS set to 'true' or '1'.
      --disable-workspace-trust          Disable Workspace Trust feature. This switch only affects the current session.
      --disable-getting-started-override Disable the coder/coder override in the Help: Getting Started page.
      --disable-proxy                    Disable domain and path proxy routes.
   -h --help                             Show this output.
      --locale                           Set vscode display language and language to show on the login page, more info see
                                         https://en.wikipedia.org/wiki/IETF_language_tag
      --open                             Open in browser on startup. Does not work remotely.
      --bind-addr                        Address to bind to in host:port. You can also use $PORT to override the port.
      --config                           Path to yaml config file. Every flag maps directly to a key in the config file.
      --socket                           Path to a socket (bind-addr will be ignored).
      --socket-mode                      File mode of the socket.
      --trusted-origins                  Disables authenticate origin check for trusted origin. Useful if not able to access reverse proxy configuration.
   -v --version                          Display version information.
      --user-data-dir                    Path to the user data directory.
      --extensions-dir                   Path to the extensions directory.
      --list-extensions                  List installed VS Code extensions.
      --force                            Avoid prompts when installing VS Code extensions.
      --install-extension                Install or update a VS Code extension by id or vsix. The identifier of an extension is `${publisher}.${name}`.
                                         To install a specific version provide `@${version}`. For example: 'vscode.csharp@1.2.3'.
      --enable-proposed-api              Enable proposed API features for extensions. Can receive one or more extension IDs to enable individually.
      --uninstall-extension              Uninstall a VS Code extension by id.
      --show-versions                    Show VS Code extension versions.
      --github-auth                      GitHub authentication token (can only be passed in via $GITHUB_TOKEN or the config file).
      --proxy-domain                     Domain used for proxying ports.
   -e --ignore-last-opened               Ignore the last opened directory or workspace in favor of an empty window.
   -n --new-window                       Force to open a new window.
   -r --reuse-window                     Force to open a file or folder in an already opened window.
 -vvv --verbose                          Enable verbose logging.
  -an --app-name                         The name to use in branding. Will be shown in titlebar and welcome message
   -w --welcome-text                     Text to show on login page

@bilogic

@bilogic My feedback about your use case:

Then, there are "company" defaults stored in Machine.json [...] not supposed to be modified in any way (I have a script that overwrites them regularly)

Frankly, this [a script that overwrites them regularly] is bad practise.

@bilogic

@bilogic About your proposed behavior A:

Overwrite with user settings on server

can be individualized, use case: developer personal preferences, sync across machines

My response:

IMHO not going to happen; Reverted by 09dd5fe
👉 Same behaviour as Codespaces now. Use 'Remote settings' (Machine settings) instead.

– #3061 (comment)

@bilogic

@bilogic What do I think?

That said, I know we can still persist to the server, but it is now all lumped together user + machine, which breaks permission controls etc

Permission controls? ~/.local/share/code-server/Machine/settings.json (Remote Settings) is located in the user's realm (home directory) and is therefore under their control - and not anyone else's.

IMHO there is only one exception: If a user deletes a setting¹ (or the whole file), e.g. by accident, it may be reinstated.
👉 If a user changes a setting, it can be assumed that this was done on purpose – even if that breaks functionality.

I think proposal A works as a way forward, alternatively, I can think of proposal B, an idea stemming from the login screen

Proposal B: we can add an entry in config.yaml to define where user settings should persist: local/server

What locations exactly do local and server refer to?

non-default; pre-populated ↩

@benz0li

@benz0li

I agree overwriting is bad practice, I'm progressively relying on permissions to do the work, but as they are not highly sensitive data, e.g. debugging ports allocated to each developer, it has taken a backseat in my todo. The idea here is to manage the new developers so that they don't have to know a ton of architecture info in order to start coding, i.e. the debugger just works
local refers to the browser's local storage, server refers to the machine that code-server is running on. In layman terms, when the developer loses his MacBook and is given a Windows machine, he can load the URL link to code-server and continue as-is without having to redo any configuration
To my understanding, you prefer to have 1 local (user) and 1 server (machine). For me, I don't mind the new 1 local (user) , I still need 2 server (user + machine)

I think we come from very different angles, mine mainly being business continuity. But I see a way to fulfil everyone's needs and I'm hoping we can move in that direction.

@bilogic

Proposal B: we can add an entry in config.yaml to define where user settings should persist: local/server

What locations exactly do local and server refer to?

If

local = Browser (on client)
server = ~/.local/share/code-server/User/settings.json (on server)

then @bilogic

Name of the CLI option for code-server?
- Option in ~/.config/code-server/config.yaml is named correspondingly?
Default setting of the newly introduced option?

@code-asher Does a new option to switch between the two behaviours (current: server, i.e. 'local storage' patch enabled; new: local, i.e. 'local storage' patch disabled) seem reasonable? (My opinion: 👍 for proposal B)
ℹ️ With the current behaviour as default, this would not even be a breaking change.

I can't seem to find the docs for config.yaml, but in my copy, there is user-data-dir, I would be able to name the new option better if there is a full overview of the options.

I can't seem to find the docs for config.yaml, but in my copy, there is user-data-dir, I would be able to name the new option better if there is a full overview of the options.

https://coder.com/docs/code-server/latest/FAQ#how-does-the-config-file-work

Each key in the file maps directly to a code-server flag (run code-server --help to see a listing of all the flags). Any flags passed to code-server will take priority over the config file.

See #6546 (comment)

@code-asher

@code-asher Regarding

Thank you for the input! So right now I think we are leaning toward keeping the patch removed and doing a major bump.

Minor bump would be fine, too.

I have a few hours left before the holidays so I might have to pick this back up on Monday, but I am going to just see if I can quickly get the old behavior working while still resolving this bug, just so we know what the alternative looks like. Maybe it will not be so bad...

👍

--user-data-storage                storage location of user data. [directory, browser]
--user-data-dir                    Path to the user data directory, ignored if user-data set to browser.

This would be my proposal, the description should use the first option as the default, and default ought to be chosen by the maintainers to minimize support questions from new users to them or based on considerations to ease maintainence.

@bilogic

--user-data                        storage location of user data [directory, browser]
--user-data-dir                    Path to the user data directory, ignored if user-data set to browser

@bilogic user-data-dir is ~/.local/share/code-server by default and there is more than just settings stored there.
ℹ️ The 'User Settings' being currently stored within this path at <user-data-dir>/User/settings.json.

@code-asher

My proposal:

Name of the CLI option for code-server?

Option in ~/.config/code-server/config.yaml is named correspondingly?

--user-settings-store Storage location of the user settings [disk, browser]

Default setting of the newly introduced option?

~~disk~~ browser

@code-asher A new option to switch between the two behaviours (current: disk (server), i.e. 'local storage' patch enabled; new: browser (local), i.e. 'local storage' patch disabled, default)

I'm probably not going to be able to test this until sometime late next week. As long as there is a way to pass in any user settings during startup, our use case should be handled, assuming that adding the patch back doesn't break the workspace file loading (which was the issue that I think initially led to removing this patch).

Basically, we use code-server to run tech training classes, and we need to set things up in a certain way for optimal student experience.

As long as we have some reasonable method to set the default for any setting and the UI refresh error that was occurring with workspace file loading is fixed, then I think we should be good to go.

@code-asher

I have a few hours left before the holidays so I might have to pick this back up on Monday, but I am going to just see if I can quickly get the old behavior working while still resolving this bug, just so we know what the alternative looks like. Maybe it will not be so bad...

@code-asher Getting "the old behavior working while still resolving #3061", #6500 and #6153 would be ideal, of course.

I think if we manage to get the old behavior working there is probably no need to also add an option because most (all?) folks will want it on the server. Having it in browser storage is really quite inconvenient. But, if folks do want an option we can consider that as a feature request.

That depends on first getting the old behavior working without bringing back the bug though...I was not able to figure it out last week.

@code-asher

@code-asher

I know the issue appeared after 4.13.0 [Bug]: Source control UI is unresponsive starting from version 4.10+ #6153 (comment)
@spkane said he will be stuck on 4.16.1, I suppose that narrows it to after that Open Workspace while another Workspace is open doesn't work. #3061 (comment), but best to confirm directly with him
If pt 2 is correct, the bug started after 4.16.1

On the road home after the holidays, but: The workspace loading UI big appeared for me after 4.16.0 which, as I recall was right before VScode saw a major Node version upgrade (to v18, I think).

…

On Mon, Nov 27, 2023 at 16:16 bilogic ***@***.***> wrote: @code-asher <https://github.com/code-asher> 1. I know the issue appeared after 4.13.0 #6153 (comment) <#6153 (comment)> 2. @spkane <https://github.com/spkane> said he will be stuck on 4.16.0, I suppose that narrows it to after that #3061 (comment) <#3061 (comment)>, but best to confirm directly with him 3. If pt 2 is correct, the bug started after 4.16.0 — Reply to this email directly, view it on GitHub <#6546 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7UXLAIJ5YAIPZO63M74DYGUUN3AVCNFSM6AAAAAA7XCUYYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYHA2TCNRSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

I think I tracked it down, I will put up an RC after CI completes!

Add back local storage patch

https://github.com/coder/code-server/actions/runs/7014210927 looks like it is cleared, can't wait! :)

https://github.com/coder/code-server/releases/tag/v4.19.1-rc.2

@code-asher

https://github.com/coder/code-server/releases/tag/v4.19.1-rc.2

code-server-4.19.1-rc.2-linux-amd64.tar.gz with Code 1.84.2 is deployed at https://coder.jupyter.b-data.ch; Image R (base:test-devtools-docker).

Resolved issued:

@code-asher Thank you for fixing these issues.

Functionality [modified by patches] tested and found to work:

base-path
cli-window-open
local-storage
marketplace
proxy-url
service-worker
webview

Jupyter Notebooks also work fine:

ms-toolsai.jupyter@2023.9.100
ms-python.python@2023.20.0

Since we got a few positive reports, I will go ahead and release 4.19.1. Thanks everyone!

Now that I have had time to get back to this, I just wanted to confirm that both issues appear to be working fine for me:

Multiple browser sessions, etc, can open up the workspace just fine, and refreshes don't lock up the explorer.
and User settings can still be passed in a stored via the filesystem.

Add back local storage patch

Navigation Menu

Repository navigation

Allow `user` setttings to persist on server (and/or browser local storage) #6546

Use case

Proposed behavior A

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow user setttings to persist on server (and/or browser local storage) #6546

Description

Use case

Proposed behavior A

Activity

bilogic commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

Footnotes

bilogic commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

bilogic commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

bilogic commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

benz0li commented on Nov 23, 2023

4 remaining items

spkane commented on Nov 23, 2023

benz0li commented on Nov 27, 2023

code-asher commented on Nov 27, 2023

bilogic commented on Nov 28, 2023

spkane commented on Nov 28, 2023

code-asher commented on Nov 28, 2023

bilogic commented on Nov 28, 2023

code-asher commented on Nov 28, 2023

benz0li commented on Nov 28, 2023

code-asher commented on Nov 29, 2023

spkane commented on Dec 28, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Allow `user` setttings to persist on server (and/or browser local storage) #6546