We also need to validate the note sizes on key-rotation.
If we do not validate them before we store them, that could lead to a
partial or total loss of the password vault. Validating these
restrictions before actually processing them to store/replace the
existing ciphers should prevent this.
There was also a small bug when using web-sockets. The client which is
triggering the password/key-rotation change should not be forced to
logout via a web-socket request. That is something the client will
handle it self. Refactored the logout notification to either send the
device uuid or not on specific actions.
Fixes#3152
The Organization member overview supports showing an icon if the user
has MFA enabled or not. This PR adds this feature.
This is very useful if you want to enable force mfa for example.
The Organization member overview supports showing an icon if the user
has MFA enabled or not. This PR adds this feature.
This is very useful if you want to enable force mfa for example.
The Organization member overview supports showing an icon if the user
has MFA enabled or not. This PR adds this feature.
This is very useful if you want to enable force mfa for example.
The Organization member overview supports showing an icon if the user
has MFA enabled or not. This PR adds this feature.
This is very useful if you want to enable force mfa for example.
As mentioned in #3111, using a very very large vault causes some issues.
Mainly because of a SQLite limit, but, it could also cause issue on
MariaDB/MySQL or PostgreSQL. It also uses a lot of memory, and memory
allocations.
This PR solves this by removing the need of all the cipher_uuid's just
to gather the correct attachments.
It will use the user_uuid and org_uuid's to get all attachments linked
to both, weither the user has access to them or not. This isn't an
issue, since the matching is done per cipher and the attachment data is
only returned if there is a matching cipher to where the user has access to.
I also modified some code to be able to use `::with_capacity(n)` where
possible. This prevents re-allocations if the `Vec` increases size,
which will happen a lot if there are a lot of ciphers.
According to my tests measuring the time it takes to sync, it seems to
have lowered the duration a bit more.
Fixes#3111
When importing to Vaultwarden (or Bitwarden) notes larger then 10_000
encrypted characters are invalid. This because it for one isn't
compatible with Bitwarden. And some clients tend to break on very large
notes.
We already added a check for this limit when adding a single cipher, but
this caused issues during import, and could cause a partial imported
vault. Bitwarden does some validations before actually running it
through the import process and generates a special error message which
helps the user indicate which items are invalid during the import.
This PR adds that validation check and returns the same kind of error.
Fixes#3048
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
