needed for web-v2023.8.2+ compatibility due to the inclusion of the new
trusted device encryption feature. without this change, the web vault
will assume that you don't have a master password set and force you to
set one.
in web-v2023.8.x the getPlans() call was changed from `/plans/` to `/plans/all`
and the create new organization form also requires a bitwardenProduct to
differentiate between plans for PasswordManager and the SecretsManager
Some optimizations in regards to downloading Favicon's.
I also encounterd some issues with accessing some sites where the
connection got dropped or closed early. This seems a reqwest/hyper
thingy, https://github.com/hyperium/hyper/issues/2136. This is now also
fixed.
General:
- Decreased struct size
- Decreased memory allocations
- Optimized tokenizer a bit more to only emit tags when all attributes are there and are valid.
reqwest/hyper connection issue:
The following changes helped solve the connection issues to some sites.
The endresult is that some icons are now able to be downloaded always instead of sometimes.
- Enabled some extra reqwest features, `deflate` and `native-tls-alpn`
(Which do not bring in any extra crates since other crates already enabled them, but they were not active for Vaultwarden it self)
- Configured reqwest to have a max amount of idle pool connections per host
- Configured reqwest to timeout the idle connections in 10 seconds
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.
When you are not loggedin, and have no cookie etc.. we always returned a 401.
This was mainly to allow the login page on all the sub pages, and after
login being redirected to the requested page, for these pages a 401 is a
valid response, since, you do not have access.
But for the main `/admin` page, it should just respond with a `200` and
show the login page.
This PR fixes this flow and response. It should prevent people using
Fail2ban, or other tools being triggered by only accessing the login page.
Resolves#3540
There now is a `v0.5` branch which will be the final release version
when the time is there. Switched to this instead of the `master` branch
which contains other fixes and enhancements as well (for `v0.6`).
This should solve all the endpoint issue we were having.
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
- Fixed issue with domains starting with `admin`
- Fixed issue with DUO not being enabled globally anymore (regression)
- Renamed `Ciphers` to `Entries` in overview
- Improved `ADMIN_TOKEN` description
- Updated jquery-slim and datatables
Resolves#3382Resolves#3415
Resolves discussion on #3288
This PR implements a (not yet fully released) new feature of Rocket which allows WebSockets/Upgrade connections.
No more need for multiple ports to be opened for Vaultwarden.
No explicit need for a reverse proxy to get WebSockets to work (Although I still suggest to use a reverse proxy).
- Using a git revision for Rocket, since `rocket_ws` is not yet released.
- Updated other crates as well.
- Added a connection guard to clear the WS connection from the Users list.
Fixes#685Fixes#2917Fixes#1424
For some reason I encountered a strange bug which resulted in sending
out multiple websocket notifications for the exact same user.
Added a `distinct()` for the query to filter out multiple uuid's.
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>
- Updated workflows to use new checkout version
This probably fixes the curl download for hadolint also.
- Updated crates including Rocket to the latest rc3 :party:
- Applied 2 nightly clippy lints to prevent future clippy issues.
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.
- Changed MSRV to v1.65.
Discussed this with @dani-garcia, and we will support **N-2**.
This is/will be the same as for the `time` crate we use.
Also updated the wiki regarding this https://github.com/dani-garcia/vaultwarden/wiki/Building-binary
- Removed backtrace crate in favor of `std::backtrace` stable since v1.65
- Updated Rust to v1.67.1
- Updated all the crates
- Updated the GHA action versions
- Adjusted the GHA MSRV build to extract the MSRV from `Cargo.toml`
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
Rocket automatically implements a HEAD route when there's a matching GET
route, but relying on this behavior also means a spurious error gets
logged due to <https://github.com/SergioBenitez/Rocket/issues/1098>.
Add explicit HEAD routes for `/` and `/alive` to prevent uptime monitoring
services from generating error messages like `No matching routes for HEAD /`.
With these new routes, `HEAD /` only checks that the server can respond over
the network, while `HEAD /alive` also checks that the database connection is
alive, similar to `GET /alive`.
Added support for Argon2 hashing support for the `ADMIN_TOKEN` instead
of only supporting a plain text string.
The hash must be a PHC string which can be generated via the `argon2`
CLI **or** via the also built-in hash command in Vaultwarden.
You can simply run `vaultwarden hash` to generate a hash based upon a
password the user provides them self.
Added a warning during startup and within the admin settings panel is
the `ADMIN_TOKEN` is not an Argon2 hash.
Within the admin environment a user can ignore that warning and it will
not be shown for at least 30 days. After that the warning will appear
again unless the `ADMIN_TOKEN` has be converted to an Argon2 hash.
I have also tested this on my RaspberryPi 2b and there the `Bitwarden`
preset takes almost 4.5 seconds to generate/verify the Argon2 hash.
Using the `OWASP` preset it is below 1 second, which I think should be
fine for low-graded hardware. If it is needed people could use lower
memory settings, but in those cases I even doubt Vaultwarden it self
would run. They can always use the `argon2` CLI and generate a faster hash.
- Updated datatables
- Added NTP Time check
- Added Collections, Groups and Events count for orgs
- Renamed `Items` to `Ciphers`
- Some small style updates
- 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.
I messed up with identation sorry it's my first PR
Fix Collection Read Only access for groups
Fix Collection Read Only access for groups
With indentation modification
With existing groups configured within an org, deleting that org would
fail because of Foreign Key issues.
This PR fixes this by making sure the groups get deleted before the org does.
Fixes#3247
During the client API login we need to have a `device_identifier`, `device_name` and `device_type`.
When these were not provided Vaultwarden would panic.
This PR add checks for these fields and makes sure it returns a better error message instead of causing a panic.
