To avoid cluttering the issue tracker with feature requests, please comment any requests here and we'll keep a list.
When available, I've linked a related issue or comment to add context to the request.
/admin/diagnostics/api/accounts/delete-recover with {"email":"[email protected]"} paramIf anyone wants to help implementing these features, we are available here or on the matrix channel to help guide you as much as we can.
What is needed for #241? Seems somebody already posted the needed changes in the corresponding issue so that could maybe be integrated?
Yes, someone would have to check those changes, see what can be integrated into the project directly (possibly a config option for the mount point) and create the documentation on how to configure the vault, proxy, etc.
@dpffxhad added it to the list
It would be great to see an (admin) feature which can help sysops to test mailing functionality. Maybe somewhere a button which can send a test e-mail to the actual user's address and which gives back a fail/success message after the action.
Good idea @Peneheals, @njfox what do you think?
Would it be possible to introduce 2FA auth to the /admin panel as well?
Good idea @Peneheals, @njfox what do you think?
I also think that's a good idea, and it shouldn't be too difficult to implement. I can look at adding the necessary API endpoints once I find some time, or knowing @dani-garcia he'll probably get to it first
About 2fa:
To do this, we'll need to implement it separately from the already existing 2fa code. I'm not sure if for this case it's worth it to implement multiple 2fa systems, so I would think just totp and maybe email would be good enough.
That said, this would require some changes to the admin page to input the 2fa code: we can't just ask for it at the start because it changes every 30 seconds .
Edit: About the email, as a workaround, you can invite yourself to test if it works for now, but it would be great to add
I am having trouble getting an Apache reverse-proxy to work in my organization. For various reasons, I can't create a new subdomain for bitwarden - i need to run it as https://my.proxy.domain/bitwarden forwarding to localhost running http on a non-standard port. However I cannot find a way to get Apache's mod_proxy to proxy from /bitwarden context to root context. For other applications I'm able to create proxies to as long as the target application uses a non-root context.
I.e. I want to do this:
https://my.proxy/bitwarden <-> http:/localhost:1234
I can get other apps to work if the internal app uses non-root context -- e.g.
https://my.proxy/acontext <-> http:/localhost:1234/anothercontext
Can bitwarden_rs be configured to listen to /bitwarden_rs or /bitwarden instead of / ? If not, can someone help in constructing apache mod_proxy / mod_rewrite rules to proxy the bitwarden_rs root context from a non-root proxy context?
@chinenual see #71. The TL/DR is that while bitwarden_rs doesn't mind serving from a sub path, client apps don't support that. There was some effort modifying the Vault code to allow this, but I haven't seen anyone reporting that they got it working.
Thanks @mprasil - I'll keep my eye on upstream client support and check back here if/when it's supportable.
@mprasil I think only the web vault needs some patching (which has already been done?)
https://github.com/dani-garcia/bitwarden_rs/issues/241#issuecomment-436373392
I changed the path in the android app and it'll correctly call api at that path.
"POST /bw/api/accounts/prelogin HTTP/1.1"
Good to know @quthla, are you sure all functionality is present in the mobile client apps - like attachments. (also this probably still rules out using the official desktop app?)
Awesome project guys!
+1 for Postgresql and/or MariaDB support.
Also +1 for groups support. I know you can use organiztions as a workaround but it is an unwieldy solution. Native support for groups would be fantastic.
support for rqlite! Bassicly a sqlite database with synchronization support across multiple servers.
As i am looking for a redundant solution
Push notifications would be cool too. I know you'd have to compile your own mobile clients for them to work but that's not such a big deal and having all your devices synced is very useful IMO.
I also like the focus on security. The option to force 2FA for all logins would make it super secure. It can be problematic letting users water down the security and effectively negating 2FA. Most people - surprisingly even informed ones - tend to choose convenience over security.
Support for custom icons? I was able to add missing icons for locally hosted sites and I'm pretty sure you could override domain icons, but what about separate icons for multiple accounts?
For customizing icons, in /data/icon_cache you can change the icons. Icons for missing domains have a *.miss extension. Copy a png file to that directory without the *.miss extension and it should render normally in the vault.
To support custom icons per cipher instead of as it is (per domain) we would probably need the clients to support them. As a possible workaround, you could create a fake invalid URL for the first URL field, like -mycustomicon1.com and use the other URL fields for the actual URL. With that you could move your custom icon to /data/icon_cache/-mycustomicon1.com.png and it should work.
Note that if you are going to keep custom icons, you should set ICON_CACHE_TTL to 0 to disable the server from renewing them in 30 days.
To expand on what @dani-garcia said above, the icons API isn't authenticated. The client just asks icon for a domain and that's all information we'll get. This is why we don't know which user is requesting the icons.
It would be nice to have the "new device logged in" emails like in the original service:
Your Bitwarden account was just logged into from a new device.
Date: Thursday, March 21, 2019 at 3:28 PM UTC
IP Address: 1.2.3.4
Device Type: WindowsYou can deauthorize all devices that have access to your account from the
web vault under Settings > My Account > Deauthorize Sessions.
Push notifications would be cool too. I know you'd have to compile your own mobile clients for them to work but that's not such a big deal and having all your devices synced is very useful IMO.
Why can't they use the push.bitwarden.com push proxy instead of requiring people to compile their own apps? If you consider it unethical, just add a statement that people should buy premium before enabling it.
@ThiefMaster is there some information about how this endpoint can be used? I've got the impression that there are some credentials needed.
Hello there. First of all many thanks for this implementation of Bitwarden! 💯
Everything is working fine but I would like to ask for two smaller things:
Both would be quite helpful to get (non-english speaking) family members to use Bitwarden. (If it's possible already I would like to know how, couldn't find any options for this.)
ability to change the application name (currently Bitwarden_rs) to my own name
Not sure if I follow you there @Kovah. Where would you like to change this? The only place I can think of are the emails - you can provide your own translated templates there.
ability to set the default language for new users
I don't think this saved or provided by the server anywhere. The setting is saved client side and as far as I know the default follows your system settings.
The users return a hardcoded Culture value of en-US at the moment, but I'm not sure if that affects the clients.
you can provide your own translated templates there.
Where would I do that? Also, it's on the login pages. Would be nice to have the own name there.
About the language thing: this would be only needed for the login page / registration form. Just tested this by changing my system language and it's set automatically. So nothing to do here. :)
Ah so you're talking about Bitwarden, not bitwarden_rs? I think you might need to recompile the vault code with your changes patched in to do that. We just use more-less direct code from upstream for that part. If you decide to do that, you can point to your version of vault via WEB_VAULT_FOLDER.
As for the templates, you can see the built-in ones here. You can modify them and mount them somewhere inside the container and then point TEMPLATES_FOLDER there.
LDAP syncing has been added to the wiki: https://github.com/dani-garcia/bitwarden_rs/wiki/Syncing-users-from-LDAP
Can we mark the LDAP thing done or is there something else that needs to be done?
Does the LDAP Synching feature simply lookup users in a LDAP directory, and send them invitation e-mails? What I was hoping for was using LDAP as an authentication backend, so that users have the same credentials to login to bitwarden_rs as they do everything else on my network that uses LDAP for authentication.
@mprasil I think we can at mark it as done, but indicate that the official ldap connector app is not supported, maybe we can add that as a separate feature.
@ImNtReal Yes, that's exactly the same thing the upstream connector app does, it just adds and removes users, but the users need to exist beforehand. I'm not sure how LDAP works internally but I imagine the passwords are hashed, so we don't have a way to get their current password to create them an account.
@dani-garcia I've updated the issue and added a sub-task to support the official thing. Although right now @ViViDboarder's solution is probably covering most of the functionality..
I'm not sure how LDAP works internally but I imagine the passwords are hashed, so we don't have a way to get their current password to create them an account.
Correct, and in most directory configurations I do not believe you will be able to retrieve the hashes.
One way to deal with the want to authenticate users via directory works much like Bitwarden works today, requiring a user-held secret to decrypt the vault -
Upon a _new_ user signing in successfully, the password they entered is used to generate the vault key.
To handle password changes, if a user signs in successfully but the derived key does not match that which was used to encrypt their vault, they would be asked to enter their old password and the vault would be re-encrypted in the same manner that a password change works now.
Unfortunately, implementing this would break compatibility with Bitwarden.
Unfortunately, implementing this would break compatibility with Bitwarden.
We could contribute equivalent functionality upstream, in order to keep us in sync. It would also aid upstream in obtaining proper directory support.
Is there a way to override the default organisation name from "bitwarden_rs" in the invitation emails that I'm missing, or is this something that'd be covered under the "better email templates" list item?
@bremensaki You can provide your own template for emails, would that work for you?
It would be nice to implement the possibility to use docker secrets, e.g. for the ADMIN_TOKEN environment variable.
Here you will find a nice article how you could implement it: https://medium.com/@adrian.gheorghe.dev/using-docker-secrets-in-your-environment-variables-7a0609659aab
@KreativeKrise, makes me wonder if we can just create symlink from /.env that is read at startup to /run/secrets/bitwarden_rs_secrets. We'd add something like this into the Dockerfile:
RUN ln -s /run/secrets/bitwarden_rs_secrets /.env
If there's no secret the service starts as usual, if you mount your own .env file, it will override the symlink, so that is still going to work as expected. Now to create the docker secrets, you'd do something like:
docker secret create bitwarden_rs_secrets - <<EOF
ADMIN_TOKEN=somelongrandomtoken
SMTP_PASSWORD=smtpserverpass
EOF
basically adding all passwords into one docker secret. That way there's no need for startup wrapper script, that we might want to then drop somehow if we want to go for distroless based image.
@KreativeKrise can't you already store your configuration in a file and mount that using Docker Secrets?
Also you can do what that blog suggests already without an upstream patch. This is one of the cool things about how Docker layers work.
The CMD in the Dockerfile is set to just run the bitwarden executable. So you could build your own Dockerfile that looks something like this:
Disclaimer: I haven't tested this, there may be small errors, but the gist is the same
FROM bitwardenrs/server:latest
COPY entrypoint.sh /
ENTRYPOINT /entrypoint.sh
Where entrypoint.sh is something like:
#! /bin/bash
source /run/secrets/bitwarden_rs_secrets
exec $@
And your secrets file is something like:
export ADMIN_TOKEN=myadmintoken
Here a few features requests :
@Pschittt
1) this is already present unless I misunderstand you here:

2) There was some discusion about it in #504 - the outcome essentially is to export your passwords with something like bitwarden-cli. I can't really imagine a scenario where you have sqlite backup, but don't have bitwarden_rs. I mean something had to create that sqlite DB right? As absolute worst case paranoid scenario, you can always backup bitwarden_rs docker image (docker save) as an fallback? It's quite small.
@mprasil
@Pschittt as for 2) see #504, there isn't much we can do server side as most of the data is client-side encrypted. There are some ideas how to achieve this, but it would most likely be external project rather than being part of bitwarden_rs.
An option not to show organization credentials in "My Vault". Currently it's difficult to separate my private credentials from organization ones.
Ability to add picture logos to organizations.
@stripe4 I think both of these will need to be implemented on the client side, so you need to make the request upstream. (In their forums)
Hi, are we likely to see the support of the official director connector any time soon?
It would depend on a third party helping with a PR, as I don't have neither the knowlege nor a server to work with LDAP.
it would be awesome to implement a simple Healthcheck to the Dockerfile.
We have the /alive endpoint that could be used to handle that check:
HEALTHCHECK CMD curl -sf http://localhost/alive || exit 1
We’d also have to handle the case where HTTPS is enabled though.
I would love to see a native backup and restore solution. currently, I am running this on k8s and it would be pretty cool to have a native backup cron of sorts running in bg
@tckb there are other containers you could attach to Bitwarden_rs for backups. I'm using images that I built for Duplicity and Restic for doing exactly what you're talking about.
Both allow you to set up cron schedule for both backups and verification. They also allow automatically restoring when the data directory is empty. Backing up a database requires a pre-backup and a post restore script.
Here's the gist of it in a gist of it... https://gist.github.com/ViViDboarder/aa480ac3411f359df80376023bc4e987
To make things simpler, I should probably have tagged images for backing up sqlite and mysql with scripts bundled.
thanks for the cue! @ViViDboarder I am thinking of setting up a k8s cron job. and container which does the backup. the k8s cron is especially makes easy to change the schedule in demand w/o needing to the build image.
@tckb wow. I really ought to switch to k8s, hah. That's super handy.
I've been using Dockron to get something similar (cron schedules to update my ddns and renew certs), but I had already built the self contained backup images. The one advantage to the all-in-one images that I shared is that it contains restoration as well. If just running backups on cron, you won't be able to automate restoration should you re-deploy on a different host. You may not care so much about this though.
With the embedded cron images linked, you don't actually have to rebuild the image to change schedule, just update the env variable and restart the container. The Dockerfile and image are only built to add the sqlite executable.
@ViViDboarder that looks interesting, are you running it in swarm? btw, http://duplicity.nongnu.org looks pretty good fit for something I am searching. Which provider are you using for storage?
@tckb for now just Docker Compose directly on each host and I use Ansible to orchestrate.
I'm using Backblaze B2 for storage. It's convenient and affordable. Both Duplicity and Restic support many backends though.
I would like to suggest to add a configurable rate limit to the API https://github.com/dani-garcia/bitwarden_rs/issues/723.
@ntimo you an have rate limiting on the proxy. I have it configured via Nginx proxy
@tckb Yes you could do it with a reverse proxy, but I personally think it would be better if the API would handle this by itself.
Hello, I was wondering if it's possible to search through the securenotes? I think this is possible in upstream: https://help.bitwarden.com/article/searching-vault/ In bitwarden_rs I made a secure note with the string "imanager' in it. When i search through the vault I would like that note to pop up.
@ajwstevens That works for me but you need to use the special syntax:
>notes:imanager
You might need to add asterisks as wildcards:
>notes:*imanager*
It's all documented in the section Advanced searches of the link you posted.
Hi all, I would like to request a new feature: audit trail logging. Allow the possibility (with an environment variable) to log which user is accessing a password in an organisation. For auditability, we would like to see when somebody is creating, modifying, or reading a password in an organisation. No need to log access to a private password, but for shared passwords in an organisation, we would like to keep an audit trail of access, in case of abuse.
@cedricroijakkers I would like that too, but think about how bitwarden works and how this would be possible. Since the passwords are synced to different devices, what forces a client to report to the server what local operations have occured?
@ptman Forgive the ignorant bliss, I'm only just starting to learn the architecture of Bitwarden, but I noticed that when opening a password in an organsation, the decription key is being downloaded from the server. Would that be a possibility?
@cedricroijakkers you probably know more than me already. I just drew conclusions from there being a sync instead of each access going to the server
Hi - I would like to suggest a new feature
Allow attachments to be stored in the database, instead of on the filesystem. This would make backups of the data easier, by only backup up the database, and would also allow clustering/redundancy of the server, by not having to rely on local storage.
Hi,
Could you add an automatic export of Key/Data as encrypted/compressed file to a targeted folder ?
For example, export to a folder backuped in cloud, if data is crypted it's not a problem.
Better if server crash :)
First of all: Thank you very much! I am using the docker image on a synology with reverse proxy, letencrypt and everything (incl. push-updates) is working very well!
I have a few questions/feature requests:
Backup
Could you let us specify a backup location and add automated backups (daily/weekly) in the admin interface.
Fantastic would be a backup plan option like 'keep daily for 30 days / weekly for 6 months / monthly for a year.
Folders
What folders are needed/possible to specify. Are there only the ones specified in the Read-only section?
Customisation
Is there a dark theme planned? If I change the web-vault folder, how can I customize the interface? Is it possbile to create child-themes?
@yelch I think the _Backup_ is somewhat inappropriate name for what should really be called _DB dump_. To have scheduled backups and to have some form of rotation is a functionality that your backup software should do, not a password management server.
There are couple interesting projects doing some automation around bitwarden_rs backups that are linked from our wiki, but generally speaking most backup software offers some form of such functionality.
Hi,
I'm wondering if it would be possible to build an ARM Docker image with Postgres enabled?
I tried generating the Dockerfile for it, but the build fails with the linker saying it can't find libpq even though it should be installed according to the Dockerfile 😕
@SuNNjek
Try checking in the docker itself if the image is actually there. Somethings you need a different reference for different platforms for certain libraries.
Something like this top open a console inside the docker image:
Docker exec $image /bin/bash
Hi,
Would it be possible to get an Alpine version from the bitwardenrs/server-postgresql docker image (as the main bitwardenrs/server variant has it already)?
Please add the ability to export and manage organizations more in-depth. A user forgot his password and I cannot delete him because he's the owner of an organization. Also when exporting user stores, organizations cannot be optionally exported.
Also, is it possible to actually sync LDAP user passwords / authenticate users via LDAP or is this not viable due to security concerns, e.g. the way stores are en-/decrypted?
I too would like a way to authenticate against LDAP. As I understant it, the bitwarden_rs_ldap is only there to invite people from your ldap tree to your bitwarden_rs instance.
It is not possible to use LDAP as the sole form of authentication without sacrificing client side decryption. At least not without completely rewriting the client applications.
I don't know if there are examples of password managers doing LDAP auth out in the wild. Even enterprise solutions like LastPass use LDAP only for provisioning/deprovisioning. https://www.lastpass.com/enterprise/directory-integration
@stanelie be aware you don't even actually "authenticate" against the bitwarden server afaik.
You authenticate your password in the client against a local datablob (recieved from the server), the result of which is used to authorise you access to your data on the server.
In contrast with LDAP the Bitwarden server never actually does the authentication itself.
So yes, what @ViViDboarder says: it would require a whole redesign, which would make it loose it's unique features compared to something like Nextcloud Passwords.
Thanks for kindly taking the time to explain that.
Hi,
hope this is the right place to issue my wishes regarding the password checking tools (weak, exposed, reused etc) :-) or is this something that should be reported to upstream "official" BW codebase ?
Many thanks
@jhf2442
This is client side only, if bitwarden adds this to the client side code, it would auto-magically also be fixed when using bitwarden_rs
Again client side only, not something related to bitwarden_rs.
Please be aware bitwarden_rs is ONLY the server side of the application. Simply put it only does the lookups in the database for the client. Everything you see and touch is mostly not a API query (Simply put: database related).
Simply put: If it grabs new data (passwords, username etc) it does a api query to the server, so in those cases its both client side (it does something you can view and interact with) and server side (it gets data).
In cases where it just sorts data differently its either just client side or a combination. (depending on coding preferences)
In cases where it's just showing weither a password is bad or not (You already have the data, just checking if its good), it's just client side.
If something has a client-side part, it can't be fixed by bitwarden_rs. As soon as bitwarden implements it it will/can be ported to bitwarden_rs.
(Yes I know this is a simplification of the API, but it's the most easy form to explain it in such a way a non-coder should be able to justify weither something is Client or Server side)
@Ornias1993 thanks for the extensive reply - Server-side API would have been enough :-)
I've submitted my feature requests on the pertaining forum at the bitwarden website ... looks like the 2nd one (sorting the weak passwords per status) was already filed last month !
In case people want to upvote these topics :
Regarding LDAP – but why wouldn't this work? We can still hold the password as is in the client application. A workflow could look like this:
Where am I going wrong? The added LDAP auth step doesn't require rewriting the client as far as I can tell(?)
@alfonsrv biggest reason is password change.
You have to maintain two passwords, which will require a client change.
@ViViDboarder right. So an option could be a fallback interface. It could trigger as soon as authentication succeeds and bitwarden_rs realizes it cannot decrypt the keys properly, redirecting to a rudimentary interface – much like the /admin – requiring a user to input both the old and new password, in order to also facilitate the password change on the bitwarden_rs side.
Where am I going wrong?
@alfonsrv I think you're ignoring the core feature of Bitwarden - client side encryption. Client does not send password as entered to the server, it sends just derived key. (which is non-reversible) So the actual password never touches server.
Which also means the server can't re-encrypt anything as it does not know the password.
@alfonsrv yes. That’s then two passwords anyway. Today, nothing stops you from changing your Bitwarden password to your LDAP password.
This was discussed earlier (in this thread or another), but Bitwarden_rs is only a server. We use the upstream clients. If Bitwarden proper adds this kind of functionality into their clients, we could do the same.
But again, I find it unlikely for the reasons mentioned earlier.
@mprasil Indeed, the whole idea is based on a flawed interprentation of how Bitwarden works:
"Bitwarden server authenticates"
Which it doesn't, authentication is client side, authorisation is (partly) server side.
"If password is authenticated against LDAP successfully"
Nice and all, but the server has no authority weither you are or aren't authencitated, so neither would LDAP.
What could work:
In theory it would be possible to let some form of middleware propagate any LDAP password changes to Bitwarden (but not visa versa).
But that middleware wouldn't be part of Bitwarden_rs as it goes out-of-scope aka it goes against the core design philosophy of bitwarden. Simply put: The bitwarden is designed around: The server never recieves or handles your password.
It would also require client side changes (for example hiding the password change options within bitwarden), which would also be out of scope for bitwarden_rs
Using the bitwarden API, you could however very well make a form of middleware thats server agnostic. It would however be a seperate github project.
@Ornias1993 yeah you could implement something outside bitwarden, but at that stage you might be better to just use something else that doesn't do client side encryption.
FWIW, LastPass has a somewhat complex solution for this, though AFAICT, it's not for AD/LDAP per se. I doubt anything like this would get implemented in upstream Bitwarden anytime soon, though.
See the "LastPass Federated Login Services" section:
https://enterprise.lastpass.com/wp-content/uploads/LastPass-Technical-Whitepaper-3.pdf
@mprasil Indeed, the whole idea is based on a flawed interprentation of how Bitwarden works:
Whoa, easy there. Indeed it was probably naive to assume it would work in a traditional web-app way; should've checked the REST calls earlier – pardon me. Would have been awesome to see it integrated – especially in order to provide a uniform logon experience across an AD infrastructure where convenient management and storage of logins against 3rd party platforms is very relevant, but I agree an LDAP implementation it is likely out of scope given what I know now.
edit: _However_, not sure how the derived key verification works, but why not let the AD server reply with a similar challenge for verification? If worst comes to worst, there's a "feature" in AD where you can store passwords reversible. Obviously not ideal, but could get the job done, no?
In order to provide a uniform logon experience across an AD infrastructure where convenient management and storage of logins against 3rd party platforms is very relevant
Ofcoarse those things are awesome, but lets be realistic: Bitwarden is not meant nor designed to work with centralised user management.
If you want LDAP user control, maybe look at Nextcloud Passwords (although the mobile os support sucks for it), however: as it supports nextcloud user mangement it would support the feature you want :)
but why not let the AD server reply with a similar challenge for verification
In that case you need quite complex middleware and my previously proposed middleware solution would be simpler/cleaner.
What you are saying is basically "Why can't I rewrite Bitwarden for LDAP?"... If you have the time and energy you could ofcorase write something that accepts the bitwarden API using LDAP. But it would require MASSIVE redesign if you would take bitwarden_rs as basis.
@alfonsrv something similar to what is in the whitepaper that @jjlin posted could do the trick, but that's a complete architecture change for auth. Client and server.
The whitepaper essentially describes what @Ornias1993 is suggesting. A middleware that they use to interface with AD.
@ViViDboarder Addition:
It would also come with a WHOLE host of potential additional security issues that need to be taken care of, so it for sure not anywhere close to "easy".
I would dare to say it might even be harder than writhing bitwarden_rs from scratch.
API Docs! Since not even the official bitwarden server implementation maintains any type of api documentation, it'd be very cool if bitwarden_rs did. It would help alot when developing 3rd party applications. While the routes and payloads aren't that complicated the response data is. It'd be great to have detailed type information about the returned data.
Would it be possible to make use of Docker Manifest Lists for a multi-arch image? I do this for all of my images, but I use Travis to automate the builds. For example, I push images to separate repos for each arch (i.e. ndanyluk/prometheus-armv6, ndanyluk/prometheus-amd64) then tag them and push a manifest list to the main repo (in the prometheus example, ndanyluk/prometheus)
This PR https://github.com/diesel-rs/diesel/pull/1884 has been merged, which could enable PostgreSQL support, by changing replace_into calls into upsert calls.
Support for SAML would be really good, but I appreciate the extra code to carry might be too much. If there is another supported auth method we could use as an adaptor to SAML I'm interested in hearing about that too.
@goetzk SAML has many of the same problems as LDAP
Being able to disable users rather than delete them would be really handy. In my case I'm considering writing a (Python) Requests script to create users but if deleting them is the only option that sounds a bit dangerous to script for the exit part of the journey.
Add slack integration to the repository so everybody can subscribe to release notifications (only the repo owner, @dani-garcia, can do it : https://slack.github.com/)
If you've never heard of it I explained (the best I could) how it works here : https://github.com/verdaccio/verdaccio/issues/1483

_Screenshot of a release notification from Harbor in our slack workspace_
@theblackhole You can subscribe to release notifications via Atom. There must be slack bots that can post rss updates. Also, isn't the chat on matrix ( #bitwarden_rs:matrix.org ) and not slack?
@theblackhole You can subscribe to release notifications via Atom.
I didn't know, how do I do that ? I haven't seen any links/button or any mention of Atom feeds in the help website.
Also, isn't the chat on matrix ( #bitwarden_rs:matrix.org ) and not slack?
The purpose here is not to have a matrix replacement but to add the Slack integration to the repository so everyone, in their own slack workspace, can get notifications for releases (or commits, issues, etc...)
@theblackhole the URL seems to be https://github.com/dani-garcia/bitwarden_rs/releases.atom (look at the html source on the releases page)
Thanks for the tip ! I will try to get it working with IFTTT then. I don't know if it will be as good as the official slack integration but it's definitely worth trying :)
It's usually not a great idea to store big files in a database, for performance reasons and that goes doubly so for SQLite. We could potentially store the small attachments in the database, but then having them divided between two places would be worse in my view.
Well the attachments folder can be set using ATTACHMENTS_FOLDER, then you can point it to a mounted network filesystem or similar. For S3 there are FUSE-based software to do it too.
And we still use the disk for the authentication keys, website icons, and config anyway, though that's mostly unimportant from a backup perspective.
Has anyone brought up using external tools to implement crypto? E.g. use a cloud KMS solution to manage encryption keys instead of putting .der private keys on the filesystem.
Also, if this could be a configurable interface of some kind, you could use Hashicorp Vault's Transit backend for crypto operations if you don't want to use a hosted cloud service.
I realize that, but the fact that bitwarden_rs uses the disk after explicitly being told not to (i.e by using mysql/postgres) is definitely surprising behaviour.
I think this is more a misunderstanding than it is a problem with bitwarden. No where in the documentation does it state setting a database means "don't use the harddrive".
It means: "use a dedicated database instead of the sqlite database."
occams razor, basically.
No where in the documentation does it state setting a database means "don't use the harddrive".
The documentation doesn't say anything about storing attachments outside of the db, or on disk either.
Actually it does.
It states the ATTACHMENTS_FOLDER folders and such are relative to the data directory if not set.
Which means the stored attachments are too ;)
If the documentation was 100% clear, nobody would run into this issue.
Statistically speaking no mater how good your documentation is, there is always someone too stupid to understand it. Considering no one hit this issue in years, I think we know where the issue lays.
But indeed lets stop this.
Request: Please publish bitwarden_rs service as snap package. That will make it really easy to install/use on linux distros without use of any containerization!
Request: Please publish bitwarden_rs service as snap package. That will make it really easy to install/use on linux distros without use of any containerization!
You can use Docker as mentioned in the README.
Request: Please publish bitwarden_rs service as snap package.
For all the downvoters: I also don't like snap but I still think that it is a reasonable request for people that do have to use snap or even like it. Please elaborate your dissent instead of simply downvoting without any explanation.
You can use Docker as mentioned in the README.
I think docker is not really an alternative for the specific snap usecases, especially if containers were explicitly excluded as a solution by @DheerendraRathor. Its like if you would have asked for a docker image so you don't have to prepare or care about dependencies and I would have told you that you can compile it from source instead.
That said, almost all packaged versions of bitwarden_rs are packaged and hosted on other locations and not here. Nobody can be stopped from building and publishing a snap on their own and it might be reasonable to separate the application from the packaging, so I'm not sure if adding snap build files or something comparable to this repository would be right. This request might be better suited to the forum.
@mqus
It isn't about snap.
Supporting packages on your own system, means supporting those... which creates a needles burden on the developer.
If you want to use it customised, building it isn't that hard either.
If I understand you correctly then you are saying basically the same thing as I wrote in the last paragraph, meaning that adding a snap package will create additional burden(1) just by needing to support the snap packaging, right? I'm basically with you there, with one small remark: The docker image(s) already are such a package and create a burden (I think at least 1/4th of the issues created are related to docker configuration and packaging issues), so it seems reasonable for people to expect "just one more" package. Additionally, snaps are intended to be packaged directly by upstream developers, so they would fit very well.
Imho the docker files should be in a separate repository (like we expect the snap package to be), but the decision was already made and I don't use docker so I'm probably not in a position to criticize that, especially when I'm not the one maintaining them.
(1) I think the snap burden would not be needless per se but indeed there don't seem to be as many users.
A snap package seems like a valid request, though I'm not sure if there is much interest from existing contributors. You can check out the Wiki to see instructions on building and packaging as well as some existing 3rd party packages that include Arch, CentOS/RHEL, and Debian.
For the time being, if you're not interested in using Docker or compatible platform, you can try those.
One small correction:
That will make it really easy to install/use on linux distros without use of any containerization!
A snap is a container. If you want a container free option, you should definitely check out the Third Party Packages.
@mqus EVERY added distribution opion ADDS a higher burden on support and development. Just because there already is one distribution option (docker) doesn't change that in any way, shape or form.
Your argument saying because there is docker, more distribution options doesn't mater is illogical and just weirdly structured at best.
That being said:
It's clear you are fishing for debate, thats why people just downvote. Not everyone has time to deal with people looking for debate on irrelevant requests they disagree with. Hence they downvote.
Hence I also ignore your attempt at trying to create a bigger discussion about docker and project structure.
I don't want to drill further down on this debate - it was just a feature request like any other, and it's okay to be downvoted/upvoted.
A snap is a container. If you want a container free option, you should definitely check out the Third Party Packages.
Thanks for this info. Wasn't really aware of it. I imagined snap as sandbox env like mobile apps.
Few comments on my requests
And yes, currently I'm building from source on my laptop and transferring binaries to hosted instance. I added feature request so deployment/update process can be streamlined. Right now, I'm subscribed to release notifications and will update my hosted app with new releases coming in.
And I'm against creating my own (or third party) packages - it creates trust issues. I would happily install packages published from an official source, but won't install from third party and neither will like anyone else to trust my package for a password manager.
So re-wording my request:
Please publish bitwarden_rs service binary on an official channel (like github packages). That will make it really easy to install/use on without use of any containerization!
Docker container processes use additional RAM. When bitwarden_rs can run within 40M RAM, why do I need container processes taking 100M additional RAM?
You could try another container engine. Podman comes to mind.
I saw the timestamp addition which is awesome! To piggyback that i would like to request formatting options as text or json. When using json logging its easier to tag logs with things like promtail :)
Limiting who can export passwords would be useful. Or even just the ability to disable it entirely.
Bitwarden just announced support for SSO: https://bitwarden.com/blog/post/bitwarden-password-manager-login-with-sso/
Does this unofficial version has any plan to add support for this feature as well?
Bitwarden just announced support for SSO: https://bitwarden.com/blog/post/bitwarden-password-manager-login-with-sso/
Does this unofficial version has any plan to add support for this feature as well?
I think we should wait till we have an actual design draft to review and/or a code audit.
my best bet would be that this feature is mostly a client side feature...
I was wrong. Its also server side supported.
(And I was an idiot, because SAML requires server-side support by-design >.<)
@dani-garcia this is a list of server-side changes to support SAML done by bitwarden official:
https://github.com/bitwarden/server/commits/fd6b10df564778ea73c00e8dcecc00aa74c5eb7d/src/Core/Enums/SsoType.cs
Technically speaking:
It's a glorified SAML reverse-proxy in front of Bitwarden, but integrated.
It does not change the fact one needs a master password to actually enter, but adds a login step.
I think this is actually more doable than it seems at first glance 👍
Feature Request:
Federation.
My coworkers all run self-hosted bitwarden_rs servers, but we want to share some passwords, so we have an organization account on one of them to share passwords with. Then, in order to use those, we have to change our backend url to the server with the org temporarily.
It would be nice if an organization account could be synced across servers. When adding a member to an org, you could optionally add a different backend url and it would sync the passwords to that user on that server.
SOCKSv5 proxy support for federation would also be nice to have.
@dr-bonez I wouldn't like to let federation anywhere near my password storage. Additionally, I think this is something that bitwarden_rs cannot really do without upstream bitwarden solving it.
But as a solution to your problem, it seems like bitwarden clients have signing on to multiple servers simultaneously in the roadmap (see Client Profiles)
Support for Event Logs would be great for organizations.
The passwords would never be in plaintext so federation as an available feature doesn't seem like much of a risk. But client profiles that support multiple backend servers would do the trick too.
Localization for emails.
Support for authenticating users via an existing JWT passed in via a header would be nice. Looking to deploy this where SSO is managed and backend apps get passed a JWT which they can then verify to identify the current user.
Would be nice to have that support here also. An example of an app that supports this is Redash (see the REDASH_JWT_* environment variables).
@ccakes This has been discussed before: This can't be done.
The server doesn't authenticate based on username and password or token. the client does based on being able to decode a snipped from the server.
@Ornias1993 Ah ok - no problem. I did look through the issues for something similar but must have missed it. Thanks for the quick response!
No problem, basically the same issues with SAML/SSO we had already:
While bitwarden implemented SAML auth, it's only on-top (or in front rather) of the bitwarden auth (so you need to just add 2 credentials instead of one). Simply because you can't decode bitwarden passwords with sending SAML/SSO/JWT(in your case) credentials, because the server isn't authoritive.
Simply put: We don't trust the server to be trustworthy enough to process passwords,
Feature request: Add custom CA certificate to trust store
I have stored multiple internal addresses within my password store and bitwarden_rs tries to fetch the favicons of the internal services as wanted. Because I am using not a publicly trusted CA for internal services, bitwarden_rs fails to fetch content.
I think the same problem could occur if a self-signed certificate/internal issued certificate is used for SMTP.
A possibility would be to add custom (root) certificates within the admin interface which are additionally trusted. This would allow bitwarden_rs to make secure connections without the use of publicly trusted certificates and without disabling certificate validation.
As a workaround, I mapped the certificates of my host into the container which extends the trusted certificate store and let update-ca-certificates execute after container creation.
-v /etc/ssl/:/etc/ssl/,ro \
-v /usr/share/ca-certificates/:/usr/share/ca-certificates/,ro \
-v /usr/local/share/ca-certificates/:/usr/local/share/ca-certificates/,ro \
Feature request: IP restriction for accessing the admin panel
It would be really nice to have an option to block all networks, excluding the networks on the list. That would increase the security of the panel, since there isn't 2FA available for it yet.
Example: block all networks, excluding the internal network 192.168.0.0/16
@davidus05
Simply restrict the /admin location in the reverse proxy?
@davidus05, i would go with @bjo81 on this.
The same goes for API rate limiting etc..
Most reverse proxies are much better in this and have a better track-record for having good blocking and security functionality.
So i think that is the best way to go.
Maybe somewhere in the future we can add it, but for now i don't think it is a priority since reverse proxies can solve that.
I can't seem to find this but if there is no option like the old LP security challenge grading your passwords and etc, would be great to have that from within bitwarden_rs
I can't seem to find this but if there is no option like the old LP security challenge grading your passwords and etc, would be great to have that from within bitwarden_rs
Please note: Bitwarden RS is only the backend server.
All things in the UI (like security checkmarks, tests etc) are not developed by BitwardenRS
One thing I'd really like is an easy way to setup connecting to an SMTP relay.
Does the env/global.override.env work? I never got it to work.
Add compatibility with docker secrets, so allow using ADMIN_TOKEN_FILE and DATABASE_URL_FILE etc so that secrets can be kept separate from the docker_compose.
If it makes implementing SSO easier, it might make sense to support an identity aware proxy like https://pomerium.io
@yegle You CAN NOT do true SSO with bitwarden, not bitwarden(tm) and not bitwardencore.
You ALWAYS need to login with your bitwarden credentials, it's by design. Simply put: the CLIENT does the authentication, not the server, there is not way bitwardenRS (The server) can support true SSO.
One thing I'd really like is an easy way to setup connecting to an SMTP relay.
Does the env/global.override.env work? I never got it to work.
I've run into the same issue. I think the global.override.env only works on the official CLI only bitwarden.
There should be an SMTP configuration implemented so we can use the email functions on home networks where smtp ports are blocked.
@VictorElHajj take a look at this comment for a possible solve for what you're trying to do. https://github.com/dani-garcia/bitwarden_rs/issues/246#issuecomment-495315985
@VictorElHajj take a look at this comment for a possible solve for what you're trying to do. #246 (comment)
@ViViDboarder & @VictorElHajj, this should be available now via this PR #1244 . So using the testing release from docker hub would have this feature.
I've just contributed a Logrotate example. Therefore it might be possible to mark Log rotation / management #305 as fixed.
I also noticed that somebody contributed an example for migration from SQLite to PostgreSQL, so Easy migration, from SQLite to other two options --> SQLite to PostgreSQL could also be marked as done.
Most helpful comment
Bitwarden just announced support for SSO: https://bitwarden.com/blog/post/bitwarden-password-manager-login-with-sso/
Does this unofficial version has any plan to add support for this feature as well?