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.
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.
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.
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.
As kinda discussed here #3090, the messages regarding loading the
configuration files is a bit strange or unclear. There have been some
other reports regarding this in the past, but wasn't that big a of a
deal.
But to make the whole process it bit more nice, this PR adjusts the way
it reports issues and some small changes to the messages to make it all
a bit more clear.
- Do not report a missing `.env` file, but only send a message when using one.
- Exit instead of Panic, a panic causes a stacktrace, which isn't needed
here. I'm using a exit code 255 here so it is different to the other
exit's we use.
- Exit on more issues, since if we continue, it could cause
configuration issues if the user thinks all is fine.
- Use the actual env file used in the messages instead of `.env`.
- Added a **INFO** message when loading the `config.json`.
This makes it consistent with the info message for loading the env file.
Resolves#3090
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
If the `YUBICO_SERVER` is defined to an empty string, the whole yubikey
implementation doesn't work anymore.
This PR adds a check for this variable that it at least starts with `https://`.
Resolves#3003
- Removed `unsafe-inline` for javascript from CSP.
The admin interface now uses files instead of inline javascript.
- Modified javascript to work not being inline.
- Run eslint over javascript and fixed some items.
- Added a `to_json` Handlebars helper.
Used at the diagnostics page.
- Changed `AdminTemplateData` struct to be smaller.
The `config` was always added, but only used at one page.
Same goes for `can_backup` and `version`.
- Also inlined CSS.
We can't remove the `unsafe-inline` from css, because that seems to
break the web-vault currently. That might need some further checks.
But for now the 404 page and all the admin pages are clear of inline scripts and styles.
As kinda discussed here #3090, the messages regarding loading the
configuration files is a bit strange or unclear. There have been some
other reports regarding this in the past, but wasn't that big a of a
deal.
But to make the whole process it bit more nice, this PR adjusts the way
it reports issues and some small changes to the messages to make it all
a bit more clear.
- Do not report a missing `.env` file, but only send a message when using one.
- Exit instead of Panic, a panic causes a stacktrace, which isn't needed
here. I'm using a exit code 255 here so it is different to the other
exit's we use.
- Exit on more issues, since if we continue, it could cause
configuration issues if the user thinks all is fine.
- Use the actual env file used in the messages instead of `.env`.
- Added a **INFO** message when loading the `config.json`.
This makes it consistent with the info message for loading the env file.
Resolves#3090
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
If the `YUBICO_SERVER` is defined to an empty string, the whole yubikey
implementation doesn't work anymore.
This PR adds a check for this variable that it at least starts with `https://`.
Resolves#3003
- Removed `unsafe-inline` for javascript from CSP.
The admin interface now uses files instead of inline javascript.
- Modified javascript to work not being inline.
- Run eslint over javascript and fixed some items.
- Added a `to_json` Handlebars helper.
Used at the diagnostics page.
- Changed `AdminTemplateData` struct to be smaller.
The `config` was always added, but only used at one page.
Same goes for `can_backup` and `version`.
- Also inlined CSS.
We can't remove the `unsafe-inline` from css, because that seems to
break the web-vault currently. That might need some further checks.
But for now the 404 page and all the admin pages are clear of inline scripts and styles.
- Updated dependencies.
This includes a janked openssl crate version we currently use.
- Updated MSRV to v1.61.0 because hashbrown/cached has this version restriction.
As kinda discussed here #3090, the messages regarding loading the
configuration files is a bit strange or unclear. There have been some
other reports regarding this in the past, but wasn't that big a of a
deal.
But to make the whole process it bit more nice, this PR adjusts the way
it reports issues and some small changes to the messages to make it all
a bit more clear.
- Do not report a missing `.env` file, but only send a message when using one.
- Exit instead of Panic, a panic causes a stacktrace, which isn't needed
here. I'm using a exit code 255 here so it is different to the other
exit's we use.
- Exit on more issues, since if we continue, it could cause
configuration issues if the user thinks all is fine.
- Use the actual env file used in the messages instead of `.env`.
- Added a **INFO** message when loading the `config.json`.
This makes it consistent with the info message for loading the env file.
Resolves#3090
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
If the `YUBICO_SERVER` is defined to an empty string, the whole yubikey
implementation doesn't work anymore.
This PR adds a check for this variable that it at least starts with `https://`.
Resolves#3003
