Why does the database change on extension login

Help
1

The Vaultwarden Backup container has this issue where the feature to backup only if the database has changed backs up every time a user logs into the server with the firefox extension.

It also backs up when .miss files appear in the icon_cache but ICON_CACHE_TTL=0 works around that.

If this login database change is unavoidable, what would be a smart way to detect “backup worthy” changes?

2

Both how the Firefox extension interacts with the backend I would imagine is handled by the official upstream Bitwarden which maintains the front end apps and the official backend server.

Vaultwarden would simply log every request that should also be captured in the official release as they try to maintain parity between the official Bitwarden server as much as possible.

How this “Vaulwarden Backup” project you linked handles difs would be up to the maintainers of that project as far as I know this is separate and not affiliated with the Vaultwarden project.
(Nonetheless still very cool and I love supporting open-source projects)

As the issue has already been raised in the project owner’s repo, I would suggest raising any further comments or suggests in that related issue thread.

3

Thanks but that doesn’t answer the question.

Certainly vaultwarden needs to respect the bitwarden protocol when talking to the extension. Why does the database change on extension login?

I don’t care about that project’s diff handling. I need to backup when a vault entry is added/removed/modified or any other significant database change. Someone logging in is not significant. How would I go about detecting “backup worthy” changes in the vaultwarden implementation?

4

Respect what protocol?

We store the last used timestamp of a device if that device logs in or uses the refresh token. It could also be that a refresh token is updated, which are stored in the database.

1 Like
5

That answers the main question of why the database keeps changing. Thanks!

I guess the followup question about detecting “backup worthy” changes is quite difficult.

In a small homelab the vault is logged into and read all the time but modifications are much more rare. The goal is to shorten the period of time a new/modified vault entry is not backed up without creating excessive numbers of equivalent backups.

6

Check if sqldiff might help.

1 Like