When a user does not have an account yet and SMTP was disabled it would
set the UserOrg status still to Accepted, though that would make it
possible to verify the user by the Org Admin's.
This would fail, since the user didn't actually crated his account, and
therefor no PublicKey existed.
This PR fixes this behaviour by checking if the password is empty and if
so, puts the user to an `Invited` state instead of `Accepted`.
Fixes#3737
- Do not update `externalId` on group updates
Groups are only updated via the web-vault currently, and those do not
send the `externalId` value, and thus we need to prevent updating it.
- Refactored some other ExternalId functions
- Prevent empty `externalId` on `Collections`
- Return `externalId` for users
Fixes#3685
In a previous commit push notifications for mobile were added, but this
introduced a header guard which caused issues with anonymous endpoints.
This PR fixes this by using a uuid with only 0's.
Fixes#3607
Merging a PR from @Kurnihil into the already rebased branch.
Made some small changes to make it work with newer changes.
Some finetuning is probably still needed.
Co-authored-by: Daniele Andrei <daniele.andrei@geo-satis.com>
Co-authored-by: Kurnihil
This is a WIP for adding organization token login support.
It has basic token login and verification support, but that's about it.
This branch is a refresh of the previous version, and will contain code
from a PR based upon my previous branch.
During setting the latest commit hash for Rocket and updating all the
other crates, there were some messages regarding the usage of `String`
for the Rocket endpoint function calls. I acted upon this message and
changed all `String` types to `&str` and modified the code where needed.
This ended up in less alloc calls, and probably also a bit less memory usage.
- Updated all the crates and commit hashes
- Modified all `String` to `&str` where applicable
the client will ignore the value of theses fields in case of `PBKDF2`
(whether they are unset or left from trying out `Argon2id` as KDF).
with `Argon2id` those fields should never be `null` but always in a
valid state. if they are `null` (how would that even happen?) the
client still assumes default values for `Argon2id` (i.e. m=64 and p=4)
and if they are set to something else login will fail anyway.
There was used a wrong macro to produce an error message when mailing
the user his password was reset failed. It was using `error!()` which
does not return an `Err` and aborts the rest of the code.
This resulted in the users password still being resetted, but not being
notified. This PR fixes this by using `err!()`. Also, do not set the
user object as mutable until it really is needed.
Second, when a user was using the new Argon2id KDF with custom values
like memory and parallelism, that would have rendered the password
incorrect. The endpoint which should return all the data did not
returned all the new Argon2id values.
Fixes#3388
Co-authored-by: Stefan Melmuk <509385+stefan0xC@users.noreply.github.com>
Since we now use the `ClientIp` Guard on a lot more places, it also
increases the size of binary, and the macro generated code because of
this extra Guard. By merging the `ClientIp` Guard with the several
`Header` guards we have it reduces the amount of code generated
(including LLVM IR), but also a small speedup in build time.
I also spotted some small `json!()` optimizations which also reduced the
amount of code generated.
There was a small bug left in regards to the web-vault v2023.2.0 fixes.
This PR fixes the left items. I think all should be addressed now.
When editing a User, you were not able to see or edit groups, or see
wich collections a user bellonged to.
Fixes#3311
- Supports the new Collection/Group/User editing UI's
- Support `/partial` endpoint for cipher updating to allow folder and favorite update for read-only ciphers.
- Prevent `Favorite`, `Folder`, `read-only` and `hide-passwords` from being added to the organizational sync.
- Added and corrected some `Object` key's to the output json.
Fixes#3279
In the org vault view, the Bitwarden web vault currently tries to fetch the
groups for an org regardless of whether it claims to have group support.
If this errors out, no vault items are displayed.
the client does not send the key on every update of an emergency access
contact so the field would be emptied on a change of the wait days or access level.
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
- Change default Password Hash KDF Storage from 100_000 to 600_000 iterations
- Update Password Hash when the default iteration value is different
- Validate password_iterations
- Validate client-side KDF to prevent it from being set lower than 100_000
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
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
Bernd Schoolmann
BlackDex
Jan Jansen
Folke Ashberg
sirux88
Daniel García
GeekCornerGH
Stefan Melmuk
Jeremy Lin
Stefan Melmuk
Jeremy Lin
Helmut K. C. Tessarek