starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-03-02 22:57:18 -05:00

[Feature Request] Allow pre-defining user settings and disabling some #256

New issue

Closed

opened 2026-02-20 08:00:51 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 08:00:51 -05:00

Owner

Originally created by @jvacek on GitHub (Mar 12, 2019).

I'd like to make sure that all of the users on the server automatically get set values in the following areas (that are different to the ones that are given by default now).
Some of these should be allowed to be changed, and some should not

Lock options (I want to make sure that the vault will always be locked within n amount of minutes)
Disable using pin lock (Password only, ever)
Disable Auto-fill (nuissance but something that I don't care for if it's changed)
Default URI Match (should be changeable if desired but seeing as we use a lot fo subdomains on our intranet, suggestions are otherwise messy)

There are many others, but basically to boil down my request: I would like to be able to set some default values for newly created users, and I'd also like the option to have some of these options "locked" so that the user cannot change them.

Originally created by @jvacek on GitHub (Mar 12, 2019). I'd like to make sure that all of the users on the server automatically get set values in the following areas (that are different to the ones that are given by default now). Some of these should be allowed to be changed, and some should not - Lock options (I want to make sure that the vault will always be locked within n amount of minutes) - Disable using pin lock (Password only, ever) - Disable Auto-fill (nuissance but something that I don't care for if it's changed) - Default URI Match (should be changeable if desired but seeing as we use a lot fo subdomains on our intranet, suggestions are otherwise messy) There are many others, but basically to boil down my request: I would like to be able to set some default values for newly created users, and I'd also like the option to have some of these options "locked" so that the user cannot change them.

deekerman closed this issue

2026-02-20 08:00:51 -05:00

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@mprasil commented on GitHub (Mar 12, 2019):

We have #246 for feature requests, so maybe submit that there. However I think all of these are set and saved only on the client side, so I'm not sure what/if we actually can do something about these settings. It sounds like you'll need to modify and compile your own version of the client apps/plugins.

I'm going to close this one, if you still feel that there's something bitwarden_rs could do to help with this, submit feature request under #246.

@mprasil commented on GitHub (Mar 12, 2019): We have #246 for feature requests, so maybe submit that there. However I think all of these are set and saved only on the client side, so I'm not sure what/if we actually can do something about these settings. It sounds like you'll need to modify and compile your own version of the client apps/plugins. I'm going to close this one, if you still feel that there's something bitwarden_rs could do to help with this, submit feature request under #246.

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@dani-garcia commented on GitHub (Mar 12, 2019):

To expand a bit on this, 2 and 3 are basically impossible from the server side. We could make an option to configure session length and to disable auto renewal for 1, but that will only kick the users out when they make a server call, so as long as they don't modify anything it won't work.

About 3, I think it would be possible to modify the ciphers url matching when they are being saved: using the default option, they send match: null, while the other options send a number, so it could be reasonable to implement, I think.

@dani-garcia commented on GitHub (Mar 12, 2019): To expand a bit on this, 2 and 3 are basically impossible from the server side. We could make an option to configure session length and to disable auto renewal for 1, but that will only kick the users out when they make a server call, so as long as they don't modify anything it won't work. About 3, I think it would be possible to modify the ciphers url matching when they are being saved: using the default option, they send `match: null`, while the other options send a number, so it could be reasonable to implement, I think.

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@mprasil commented on GitHub (Mar 12, 2019):

Good point about the 3rd thing @dani-garcia, I have forgotten that the match detection wasn't always configurable and there was just null used for backwards compatibility. I think it could be even more helpful if we could just return some set DEFAULT_MATCH_DETECTION for any null setting stored. That way you can set/change the default server-wide rather than having to re-save all items on any default change.

@mprasil commented on GitHub (Mar 12, 2019): Good point about the 3rd thing @dani-garcia, I have forgotten that the match detection wasn't always configurable and there was just null used for backwards compatibility. I think it could be even more helpful if we could just return some set `DEFAULT_MATCH_DETECTION` for any `null` setting stored. That way you can set/change the default server-wide rather than having to re-save all items on any default change.

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@dani-garcia commented on GitHub (Mar 12, 2019):

The problem with storing null and returning a different value is that when the user edits the cipher, they'll have the returned value selected in the dropdown, and they'll send it when submitting instead of the initial null, so we are basically in the same place, just a bit later.

I think it would be better to be consistent in this case and just save it all the time.

@dani-garcia commented on GitHub (Mar 12, 2019): The problem with storing null and returning a different value is that when the user edits the cipher, they'll have the returned value selected in the dropdown, and they'll send it when submitting instead of the initial null, so we are basically in the same place, just a bit later. I think it would be better to be consistent in this case and just save it all the time.

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@matlink commented on GitHub (Aug 1, 2023):

What should be the behavior when the user has changed the matching algorithm in its settings? match: null can then either be user default or server default.
EDIT: this is somewhat not important since whatever we want to do, the user settings are stored client side so we can't know it has changed the default matching algorithm in its settings.

@matlink commented on GitHub (Aug 1, 2023): What should be the behavior when the user has changed the matching algorithm in its settings? `match: null` can then either be user default or server default. EDIT: this is somewhat not important since whatever we want to do, the user settings are stored client side so we can't know it has changed the default matching algorithm in its settings.

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@matlink commented on GitHub (Aug 3, 2023):

The problem with storing null and returning a different value is that when the user edits the cipher, they'll have the returned value selected in the dropdown, and they'll send it when submitting instead of the initial null, so we are basically in the same place, just a bit later.

I think it would be better to be consistent in this case and just save it all the time.

Can't we do both? If we only save upon submission, the changes would be applied only when users save a cipher. If we do both, it applies immediately as default matching would be replaced by the admin-overridden one when vaults get synced (but it requires to iterate over all the ciphers which is probably too costly).

@matlink commented on GitHub (Aug 3, 2023): >The problem with storing null and returning a different value is that when the user edits the cipher, they'll have the returned value selected in the dropdown, and they'll send it when submitting instead of the initial null, so we are basically in the same place, just a bit later. > > I think it would be better to be consistent in this case and just save it all the time. Can't we do both? If we only save upon submission, the changes would be applied only when users save a cipher. If we do both, it applies immediately as default matching would be replaced by the admin-overridden one when vaults get synced (but it requires to iterate over all the ciphers which is probably too costly).

deekerman commented

2026-02-20 08:00:52 -05:00

Author

Owner

@rvjr commented on GitHub (Apr 23, 2024):

@jvacek I'm glad I found your issue while searching for the default URI matching. Besides default URI matching set to 'host', the default auto-lock timeout was also high on my wish list. Just to have some reasonably safe configuration for all user who don't care to set any of these options. Did you find any solutions for your open points yet?

@rvjr commented on GitHub (Apr 23, 2024): @jvacek I'm glad I found your issue while searching for the default URI matching. Besides default URI matching set to 'host', the default auto-lock timeout was also high on my wish list. Just to have some reasonably safe configuration for all user who don't care to set any of these options. Did you find any solutions for your open points yet?