Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jvacek opened this issue Mar 12, 2019 · 7 comments
Closed

Comments

@jvacek
Copy link

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

@mprasil
Copy link
Contributor

mprasil commented 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 mprasil closed this as completed Mar 12, 2019
@dani-garcia
Copy link
Owner

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.

@mprasil
Copy link
Contributor

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

@dani-garcia
Copy link
Owner

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.

@matlink
Copy link
Contributor

matlink commented 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
Copy link
Contributor

matlink commented 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).

@rvjr
Copy link

rvjr commented 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants