* Update twofactor_email.hbs subject line to avoid triggering gmail content filter
Previous subject line was triggering Google's spam blocker, breaking the 2FA setup process if a gmail SMTP server is configured. The new subject line does not (currently) run afoul of Google's filter.
* Update twofactor_email.html.hbs subject line to avoid triggering gmail content filter
Previous subject line was triggering Google's spam blocker, breaking the 2FA setup process if a gmail SMTP server is configured. The new subject line does not (currently) run afoul of Google's filter.
* Update twofactor_email.hbs
Changed "Confirmation" to "Verification" for the sake of internal consistency
* Update twofactor_email.hbs
* Update twofactor_email.html.hbs
While working on the fix I realised the location where the `external_id`
is stored was wrong. It was stored in the `users` table, but it actually
should have been stored in the `users_organizations` table.
This will move the column to the right table. It will not move the
values of the `external_id` column, because if there are more
organizations, there is no way to really know which organization it is
linked to. Setups using the Directory Connector can clear the sync
cache, and sync again, that will store all the `external_id` values at
the right location.
Also changed the function to revoke,restore an org-user and set_external_id to return a boolean.
It will state if the value has been changed or not, and if not, we can
prevent a `save` call to the database.
The `users` table is not changed to remove the `external_id` column, thi
to prevent issue when users want to revert back to an earlier version
for some reason. We can do this after a few minor release i think.
Fixes#3777
The PostgreSQL migrations do not need this setting.
I tested this by running an old Vaultwarden instance (v1.18.0) on a new
PostrgreSQL database, created a few users and some vault items, after
that run the new code and it doesn't break.
Fixes#3930
During a WebSocket connection we currently also send several headers
which could cause issues with some reverse proxy, or with the CloudFlare
tunnel for example. This PR resolves these issues.
Fixes#3881
It looks like either something changed in the latest v2023.8.x versions,
or when using Biometrics to login, but the MasterPasswordHash is an
optional value during the Approve action.
This PR makes the MasterPasswordHash an optional value which resolves
this issues. Bitwarden works the same way.
I also changed the EncKey to an Option in the database since empty
strings as a default value is not nice in databases, better to use
`null` in these cases.
Fixes#3819
- Updated the admin interface dependencies.
- Replace bootstrap-native with bootstrap
- Added auto theme with an option to switch to dark/light
- Some small color changes
- Added an dev only function to always load static files from disk
Some clients (Thirdparty) might use the `Authorization` header instead
of a query param. We didn't supported this since all the official
clients do not seem to use this way of working. But Bitwarden does check
both ways.
This PR adds an extra check for this header which can be optional.
Fixes#3776
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
aureateflux
Adrià Martín
Tobias Bölz
BlackDex
Mathieu Valois
tuhana
Stefan Melmuk
Stefan Melmuk
Bernd Schoolmann
GeekCorner
Jan Jansen
Folke Ashberg
sirux88
Daniel García
Jeremy Lin