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

[bilogic]

Continued from #3061 (comment)

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

Use case

1. Our developers store their individualized user settings on the server, and this gives the same settings even on new machines
2. 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)
3. I use workspace to store project settings, they contain minimal settings, mainly folder paths settings
4. 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

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

[bilogic]

In response to the comments after #3061 (comment)

1. 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
2. A laptop/browser is also not the best place to be storing data, it is not ideal for business continuity (backup/device loss etc)
3. I have been telling colleagues/friends about how I can lose my laptop and still continue from where I was in minutes
4. 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
5. 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
6. I think proposal A works as a way forward, alternatively, I can think of proposal B, an idea stemming from the login screen
7. Proposal B: we can add an entry in config.yaml to define where user settings should persist: local/server

What do you guys think?

[benz0li]

@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

[benz0li]

@bilogic My feedback about your use case:

2. 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.

[benz0li]

@bilogic About your proposed behavior A:

2. 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)

[benz0li]

@bilogic What do I think?

5. 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.

6. I think proposal A works as a way forward, alternatively, I can think of proposal B, an idea stemming from the login screen
7. 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?

Footnotes

1. non-default; pre-populated ↩

[bilogic]

@benz0li

1. 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

2. 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

3. 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.

[benz0li]

7. 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

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

then @bilogic

1. Name of the CLI option for code-server?
   • Option in ~/.config/code-server/config.yaml is named correspondingly?
2. 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.

[bilogic]

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.

[benz0li]

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)

[benz0li]

@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...

👍

[bilogic]

--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.

[benz0li]

--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.